aptpod Tech Blog

株式会社アプトポッドのテクノロジーブログです

DockerでEC2にintdash建ててみた

製品紹介 サーバーサイド インフラ・SRE AWS Linux

開発・検証用にintdashサーバーを動かしたいエンジニアのみなさん、

こんにちは、ソリューションアーキテクトの伊勢です。

intdashの2025年版からDockerでサーバー環境を構成できるようになりました。

製品マニュアルページで サーバーの構築 の1パターンとして

AWS EC2上のDocker（簡易環境） の構築手順を公開しています。1

今回はその理解を助けるため、各ステップの目的・準備・結果確認を噛み砕いてintdash環境を構築し、サーバーのログや設定を確認してみます。2

はじめに

全体の流れ

全体像を捉えられるようにサーバーの構成から説明します。

  1. サーバー構成の説明
  2. EC2上にDockerでintdashサーバーを構築
  3. ブラウザ・Motionから接続確認
  4. データ送信とログ確認
  5. 負荷・データ・設定の確認

サーバー構成

通常、intdashのサーバーサイドは、2種類のインスタンスで構成されます。3

  • APIインスタンス
    • Webサーバー、API、認証、データ伝送、データやメディア管理
  • DBインスタンス
    • ユーザー／エッジ／計測の保存、計測の時系列データの保存

通常のインスタンス・サービス構成

簡易環境では、1つのEC2インスタンスにAPI/DB双方のサービスが同居します。4

EC2簡易環境

AWS CDK

簡易環境の構築にはAWS CDK（AWS Cloud Development Kit）を利用します。

AWS CDKとはインフラ構成をコードで記述したもので、このコードは AWS CloudFormation のテンプレートに変換されます。

AWS CloudFormation は、インフラ構成を定義したテンプレートで自動的に構築・更新・削除するサービスです。

CDKで生成したテンプレートをもとに CloudFormation がインフラを構築・更新・削除を自動化、状態を管理します。

構築手順イメージ

構築手順は大まかに

①〜③インフラ構築

④〜⑥アプリ構築

にわかれます。

構築手順

  • 作業用PC
    • AWS CDKでテンプレートを生成してCloudFormationを起動します。
  • AWS CloudFormation
    • テンプレートと元にAWSリソースを構築します。
  • EC2インスタンス
    • Docker Composeで各サービスのコンテナを構成・起動します。
    • コンテナ構成定義から環境変数を読み込みます。

手順前提

事前に以下が必要です。

  • 作業用PC
    • AWS CLI、およびAWS CDKを実行します。
    • マニュアルのコマンドはLinux準拠です。5
  • AWSアカウント
    • EC2などのリソースが構築されるAWS環境です。
  • AWS IAMユーザー
    • 作成するAWSリソースに権限が付与されている必要があります。
  • intdashライセンス アクティベーションキー
    • intdashサーバーを有効化するため、設定します。
    • intdashライセンスを契約すると発行されます。
  • サーバードメイン名
    • サーバーにFQDNでアクセスするために必要です。
    • 今回はAWS Route53で払い出す手順を紹介します。

ツール準備

作業用PCに必要なツールがインストールされているか確認します。

  • AWS CLI
    • EC2へのSSH接続時、AWS CDK実行時の認証に使います。
  • Node.js
    • Node.js 本体のバージョン管理ツールです。
    • npm パッケージを実行ツールです。AWS CDKスクリプトを実行します。
aws --version

node -v
nvm --version
npm --version

Node.jsのバージョンが古かったので最新版をインストールしました。

AWS CLI、Node.js / npmの確認

環境構築

準備

マニュアルの通り、以下を準備します。6

  • AWS CLIの認証情報
    • キーペア作成、AWS CDKデプロイ時の認証のために設定します。

AWS CLI認証情報

EC2インスタンス構築

ここからインフラ構築を始めます。

まず、作業用PCで実行するデプロイ資材をダウンロードします。

CDK資材ダウンロード

インタラクティブモードでAWS CDKのセットアップを開始します。

セットアップ開始

今回、intdash最新バージョンにあわせてRocky Linux 9イメージを使用します。7

rockylinux.org

  • Version: 9.7
  • Region: ap-northeast-1
  • Architecture: x86_64

Rocky Linux9.7イメージのAMI IDをコピー

確認したRocky Linux 9イメージのAMI IDを指定してデプロイします。

また、削除時のElastic IP保持を指定しています。

Elastic IPを確認

生成されたペアキーを安全な場所に置き、

EC2インスタンスにログインできるか確認します。

mv ./intdash-trial-key.pem ~/.ssh
ssh -i ~/.ssh/intdash-trial-key.pem rocky@<Elastic IP>

sudo su - intdash

ログイン確認

アプリ起動

セットアップが完了すると、すでにintdashサーバーが起動しています。

起動確認

ブラウザでhttps://intdash.<Elastic IP>.nip.ioにアクセスします。

ログイン画面

ログインしてProject Consoleが表示されることを確認します。

Project Console画面

もしアクセスできない場合はログを確認します。

# ステータス確認
sudo systemctl status intdash-trial

Docker Composeの全コンテナのログを確認する方法です。

auth-1などコンテナ名が表示されます。

# リアルタイム表示
journalctl -u intdash-trial -f

# 直近100行
journalctl -u intdash-trial -n 100

# 直近10分
journalctl -u intdash-trial --since "10 minutes ago"

全コンテナログ

ログインできない場合、Authentication Serviceのログを確認します。

特定コンテナのログを表示する方法です。

Docker Composeのサービス名authを指定します。

cd ~/deployment/

# 直近100行
docker compose -f docker-compose.yml logs auth | less

# 直近10分
docker compose -f docker-compose.yml logs auth --since 10m | less

特定コンテナログ

SSLサーバー証明書設置

このままではHTTPS通信ができません。

ブラウザではアクセスできますが、今回エッジとして利用する intdash Motion でアクセスできません。

続きの手順でHTTPS通信できるようにします。

SSLサーバー証明書設置前

今回は以下のように準備しました。

  • サーバードメイン名
    • 今回はAWS Route 53で取得します。
サーバードメイン名の準備

本記事用に取得しています。

AWS Route53でドメイン名を購入します。最安で$15/月です。

ドメイン購入

登録に数分かかります。

完了するとVerifyメールが届きます。クリックします。

ドメイン登録のVerifyメール

EC2インスタンスのIPアドレスを割り当てるサブドメインのレコードを作成します。

サブドメインレコード作成

全世界のDNSサーバーに登録が開始され、しばらくすると名前解決できます。8

dig <サブドメイン名>

名前解決成功

Let's Encryptで証明書設定

EC2インスタンス上でHTTPS通信のための証明書・秘密鍵を生成します。

Let’s Encrypt の証明書発行ツール Certbot をインストールする前に、Rocky Linuxのパッケージ管理コマンド DNF（Dandified Yum） で追加パッケージリポジトリ EPEL（Extra Packages for Enterprise Linux） をインストールします。

sudo dnf install -y epel-release
sudo dnf makecache

EPELインストール

マニュアル通り、Certbot でSSLサーバー証明書と秘密鍵を発行します。

SSLサーバー証明書・秘密鍵発行

intdashサービス起動の前に、デプロイ資材の環境変数FQDNを取得したサブドメイン名に変更します。

FQDN変更

これで intdash Motion でHTTPSアクセスできるようになります。

intdash MotionでHTTPSアクセス

メールサーバー設定

マニュアル通りにメール設定を環境変数に追加します。

元の

AUTH_SMTP_ADDRESS: "mail:1025"
AUTH_SMTP_HOSTNAME: "auth"

はコメントアウトします。9

メールサーバーと通知メール送信元を設定

AUTH_SMTP_PASSWORD に設定する <Gmail用のアプリパスワード> は

Googleアカウント > 2段階認証プロセス > アプリ パスワード

で発行します。

アプリパスワードの発行

管理者ユーザー設定

マニュアル通り、管理者ユーザーのメールアドレスを登録します。

メールアドレス追加

確認メール

メールアドレス確認済み

Google Maps APIキー設定

Google Maps APIキーを準備します。

  • Map JavaScript APIを有効化します。
  • 自サイトだけで利用できるようウェブサイトでアプリケーションの制限を設定しておきます。

Google Maps APIキー準備

あとはマニュアル通り、Google APIキーを設定します。

Google Maps APIキー設定前

Google Maps APIキー設定後

計測開始

intdash Motion起動

intdash Motion の計測を起動します。

アップストリームを Edge Finder 、作成された計測を Meas Hub で確認します。

Edge Finderの確認

Meas Hubの確認

ログ確認

確認コマンド

全コンテナのログは journalctlで確認できます。

journalctl -u intdash-trial -f
journalctl -u intdash-trial -n 100
journalctl -u intdash-trial --since "10 minutes ago"

各テナントのログはDocker Composeの logs コマンドで確認できます。

cd deployment/
docker compose -f docker-compose.yml logs <container> | less
docker compose -f docker-compose.yml logs <container> --since 1h | less

なお、本構成では特にDocker Composeのロギング設定をしていません。10

計測時のログ確認

計測起動時のBroker Serivceコンテナのログを確認してみます。

docker compose -f docker-compose.yml logs broker -f

Broker Serviceコンテナログ

WebSocket接続

Motionで計測を開始すると、一度WebSocketが切断されます。

"msg":"Received Disconnect"

その後、改めてWebSocketの接続ログが出力されます。

"msg":"Received WebSocket:\tua:Motion/49 CFNetwork/3860.400.51 Darwin/25.3.0 referer: remote_ip:xxx.xxx.xxx.xxx:46928 proto:HTTP/1.1"
"msg":"Received ConnectRequest request_id:0  protocol_version:2.0.0"
"msg":"Authenticated by OAuthToken subject:c82b7aba-b9e1-46a8-a8b4-87c7384ce140"
計測新規作成
"msg":"Received","tenant_id":0,"project_id":"00000000-0000-0000-0000-000000000000","user_id":"c82b7aba-b9e1-46a8-a8b4-87c7384ce140"
"path":"/api/v1/projects/00000000-0000-0000-0000-000000000000/measurements"
アップストリーム開始
"msg":"Received UpstreamOpenRequest request_id: 2  session_id: 6fd90f07-0dca-47f0-8419-776b995bc876 qos: unreliable ack_interval: 100ms expiry_interval: 1m0s persist: true"
"msg":"Succeeded in opening upstream. id=[4f5442cf-74e3-4f98-9695-0f566f5a3127] qos=[unreliable]","tenant_id":0,"message_track_id":"8565-2830-1198","transport_track_id":"4629-1820-3724"
基準時刻受信
"msg":"Received UpstreamMetadata request_id: 4 metadata: *message.BaseTime"

計測開始からここまでが一気に出力されます。

データ伝送

継続中は以下が続きます。

"msg":"MessageCount rx: 0 [msg/sec] tx: 3 [msg/sec]","tenant_id":0,"message_track_id":"6601-6588-7707","transport_track_id":"1239-5713-3538"
..
"msg":"MessageCount rx: 1 [msg/sec] tx: 6 [msg/sec]","tenant_id":0,"message_track_id":"6601-6588-7707","transport_track_id":"1239-5713-3538"
計測停止

Motionで計測を停止すると以下が出力されます。

"msg":"Received UpstreamCloseRequest request_id: 8  stream_id: 4f5442cf-74e3-4f98-9695-0f566f5a3127"

stream_id は Succeeded in opening upstream. の id と一致しています。

負荷確認

運用でよく確認するサーバー負荷を見てみます。

Motion から以下のデータを5分間ほど送信します。

わかりやすく負荷を上げるために映像データを最大量で送信してみました。11

  • 映像: H.264
    • FullHD
    • 30 FPS
    • 8.2 Mbps
  • 音声: PCM
  • IMU
  • GPS

瞬間的に8〜12 Mbps超

AWSコンソール

AWSコンソールで推移を確認します。

AWSコンソールの確認

CPUが40%、データ受信が40 MB（≒ 5.5 Mbps）を超えています。

top コマンド

top コマンドでメモリの推移を確認します。

top コマンド確認

メモリ使用は 6.5 GBを超えています。

なお、データ格納領域 /data が 98 GB ほど使われています。

df コマンド確認

設定

設定確認

秘匿情報や環境固有情報は、デプロイ資材の.envファイルからDocker Composer設定ファイルに伝播するようになっています。

例えば、先ほど設定した FQDN は NGINX_SERVER_NAME などに伝播します。

docker-compose.yml

設定変更

では、一部の設定を変更してみましょう。

バックエンド：ログイン試行回数変更

わかりやすい例として Authentication Service の設定を変更します。

  • Authentication Service
    • user-password
      • attempt-limit: パスワード試行回数のリミット
        • デフォルト値: 5
        • この回数間違えるとユーザーはロックされます。
        • 正しいパスワードでもログインできなくなります。
        • ログインするにはロック解除かパスワード再発行が必要です。

Authentication Serviceの項目を持つ docker-compose.api.yml を編集します。

パスワード試行回数のリミットを1回に変更します。

サービス名、セクション名、設定項目をつなげて項目名を

AUTH + _ + USER_PASSWORD + _ + ATTEMPT_LIMIT にします。

      AUTH_USER_PASSWORD_ATTEMPT_LIMIT: 1

サービス auth を再起動します。

docker compose up -d auth

パスワード試行回数の変更・再起動

Admin Consoleでユーザー test を作り、ログインを1度失敗します。

ログイン失敗

intdash ユーザーで test ユーザーを確認すると "ロック中" になっています。

ログイン試行1回失敗でロック中

フロントエンド：ロゴ変更

例外として、フロントエンドはWebデプロイ資材を直接書き換えます。

今回はData Visualizerのロゴを変更してみます。

標準は画面左上に出てくるVISUAL M2Mの画像です。

標準ロゴ

以下の設定項目を変更します。

  • VM2M Data Visualizer（フロントエンド）
    • vm2m-2nd-configの設定
      • header
        • logoImgURL: Data Visualzierのヘッダロゴ

AWS S3に配置・公開した 幅200px、高さ56px のPNGファイルを指定します。

PNGファイルS3配置

cd deployment/
vi docker/ui-conf/vm2m-data-viz-backend/config/vm2m-2nd-config/vm2m-2nd-config.production.json

  "header": {
    "logoImgURL": "https://s3.ap-northeast-1.amazonaws.com/<S3_BUCKET_NAME>/docker.png"
  },

vm2m-2nd-configの編集

Data Visualizerサービスを再起動してData Visualizerを表示します。

docker compose restart vm2m-data-viz-backend

カスタムロゴ

おわりに

Dockerで開発用のintdash環境を構築してみました。

普段は意識しないサービスやDB構造を確認することで理解が深まり、

設定やログ、パフォーマンスを見ることで運用イメージがつきました。

設定項目は他にも多くあるので、また別の機会にご紹介できればと思います。

  1. 簡易環境の構築方法としては、これまでAWS マーケットプレイスにAMIを提供していました。コンテナイメージとDocker Composeでの仮想化により、AWS以外での構築方法と統合され、バージョン最新化も容易になりました。↩
  2. 構築および運用手順はintdashの公式マニュアルをご参照ください。閲覧にはユーザー登録が必要です。↩
  3. 冗長構成では各サービスごとにインスタンスが細分化、またスケールアウトします。↩
  4. 簡易環境は開発用途の構成であり、本格的な運用には向きません。本番環境向けの構成は Kubernetes または RPM で構築します。↩
  5. WindowsではWSLのUbuntu環境などで実行できます。↩
  6. 本記事では、基本的に公式マニュアルに沿って進め、各ステップで「どういう目的で何が行われているか」「構築結果をどう確認するか」にフォーカスして解説します。↩
  7. 利用するAMI IDはリージョンなどにより異なるため、Rocky Linux公式サイトで最新のものを確認してください。↩
  8. ICMPポートは開けていないため、pingは通りません。↩
  9. デフォルトではコンテナ内のSMTP（mailコンテナ）を使用していますが、外部SMTP（Gmail等）を利用するように変更します。↩
  10. ログはDockerコンテナが再作成されると消えてしまいます。必要に応じて Docker Compose の設定で syslog 等で外部保存します。↩
  11. なお、Motion側のWi-Fi帯域を超えており、データ量の86.4 %しか送信できていません。↩