はじめに TDU_データ科学・機械学習研究室AdventCalendar1日目 普段は深層学習を用いた伝統文様の画像解析をしています． 普段研究ではDockerを用いてGPUサーバ上で作業をしています． GPUマシン上にDockerを立てて，その中にPythonやら機械学習の環境を構築しています．メインとするGPUマシンにローカルマシン(MacBook)からvscodeのRemoteDevlopementを利用してアクセスしています．しかし，Dockerを利用しているためvscodeのAutoCompletionを利用するには特殊な設定が必要です． https://code.visualstudio.com/docs/remote/containers Dockerの環境を用いて開発するのはとても便利ですが，vscodeの補完機能が利用できないのはやはりコーディングが難しいです．また，vscodeのデバッガーが起動できないため基本pdbやプリントデバッグを利用してデバッグするためコードの理解に時間がかかります． そこで，code-serverを普段利用してるDockerfileに追記をすることで起動させ，デスクトップ版のvscodeっぽく利用してしまおうという魂胆です． デスクトップ版のcode-serverを利用するメリットは下記のようなものがあります． code-server利用のメリット 開発がマシンによらない． Desktop版のvscodeと違い，リモートマシンにアクセスできればどこから(PC, タブレット，スマホ)でも開発が可能です． エディタがコードベースで管理可能 code-serverの起動やvscodeの拡張機能含め，Dockerfileに記述をするので，GitHubでの管理可能です． 手順 ここからはDockerfileを作りながら最終的にcode-serverを起動できるようにする手順を書きます． 1. DockerHubより手ごろなイメージを探す． 下記サイトよりpytorchのDockerイメージを探します． https://hub.docker.com/r/pytorch/pytorch/tags 1.8.0-cuda11.1-cudnn8-runtime ハイフンでつながれているのがそれぞれpytorch, CUDA, cudnnのバージョンです． 適宜自分の環境に合うように利用してください． 研究で利用しているプログラムもあるので私はpytorch1.8.0のバージョンを使います． 2. ベースとなるイメージからDockerfile作成 ここからはDockerfileをいじります． Dockerfileの一行目には下記のようにベースとなるイメージを指定します． Dockerfile FROM pytorch/pytorch:1.8.0-cuda11.1-cudnn8-devel それ以降は環境構築に必要なコマンド等を記述します． 僕のファイルは以下のようになります． Dockerfile FROM pytorch/pytorch:1.8.0-cuda11.1-cudnn8-devel # Install vim RUN apt-get update && apt-get install -y vim WORKDIR /workspace ADD requirements.txt /workspace # install git RUN apt-get update && apt-get install -y git # install python modules RUN pip install -r requirements.txt # install hydra RUN pip install hydra-core --upgrade # 日本語化 RUN apt-get update \ && apt-get install -y locales \ && locale-gen ja_JP.UTF-8 \ && echo "export LANG=ja_JP.UTF-8" >> ~/.bashrc 3. code-server構築手順をDockerfileに記述 Dockerfileの最終行には下記を追加してください． ~~~~~途中~~~~~ RUN apt-get update && apt-get install -y curl RUN curl -fsSL https://code-server.dev/install.sh | sh RUN code-server \ --install-extension ms-python.python \ --install-extension ms-ceintl.vscode-language-pack-ja 3. docker-compose.yml作成 docker起動コマンドをすっきりさせたいのと，複数コンテナ利用するための拡張性のためにdocker-compose.ymlを作成します． docker-compose.yml version: '2.3' services: pytorch-docker: build: context: ./Docker dockerfile: Dockerfile shm_size: '2gb' container_name: torch-docker user: "${UID}:${GID}" runtime: nvidia # command: /bin/bash # command: jupyter lab --port 9999 --ip=0.0.0.0 --allow-root --NotebookApp.token='' --NotebookApp.password='' command: code-server --port 8080 --bind-addr=0.0.0.0:8080 /home/shuzo --log debug ports: - "7000:7000" - "9999:9999" - "8501:8501" - "0.0.0.0:8080:8080" - "0.0.0.0:8443:8443" environment: - TZ=$TZ - LANG=$LANG - PASSWORD=$PASSWORD tty: true volumes: - ./:/workspace - /etc/passwd:/etc/passwd:ro - /etc/group:/etc/group:ro 4. .envファイルに記述 Dockerfileと同じ階層に.envファイルを用意します． .env UID=xxx GID=xxx TZ=Asia/Tokyo PASSWORD=xxxxx .envファイルに記述してしまってますが，多分よくありません． 何かいい方法あれば教えてください． 5. 起動&アクセス sudo docker-compose up --build で起動できます． 無事起動ができたら， ブラウザで<起動したサーバのIP>:8080にアクセスしてください． 6. 補完機能を有効化 Docker内にあるAnacondaのPathを通します．これをすることでcode-server上で補完機能が利用できます． 1. まず，pythonの拡張機能をインストールしてください． 2. 設定で，interpreterを検索 3. Python Pathに/opt/conda/bin/python3を追加 おわりに 今回紹介する内容はGitHubで公開しています．逐次アップデート予定 参考

ここでは、Oracle Database の最新機能の一つ Oracle Graph を無料で手軽に試すため、手元の Docker コンテナ上に構築する方法を紹介します。Oracle Database の初回起動など多少の時間がかかりますが、待っていれば終わりますので是非お試しください。 まずは Oracle Graph のアーキテクチャの概観は次の通りです。Oracle Database 単独でもグラフ・データベースとして機能しますので（2-tier deployment）まず前半ではこの構成を扱います。後半では Graph Server というインメモリのグラフ分析フレームワークを追加することで、超高速なクエリやグラフアルゴリズムの実行を可能にします。 それなら Oracle Database は要らないから Graph Server だけを使いたいよ、という方もいらっしゃるかもしれません。そういう方法がないわけではない（ハックしていただけると思う）のですが、Graph Server でも Oracle Database のユーザー認証を用いることで、できる限りシームレスなデータ連携と企業用途のセキュリティを実現しようというのが Oracle Graph の思想です。 データベースの構築 もしも既に利用できる Oracle Database（バージョン 12.2 以降）をお持ちであればそちらをお使い頂くこともできますので、その場合は次項「Oracle Graph の有効化」に進まれてください。 もしも Docker 上に構築するのであれば Oracle Container Registry から Express Edition (XE 18c) のイメージを入手することをおすすめします。ご存じない方も多いかと思いますが Express Edition を使えば、サイズの制限があるものの（2CPU スレッド、2GB RAM、12GB のユーザーデータ）小さなデータベースであれば Oracle Database のほとんどの機能を無料で使うことができます。もちろん Oracle Graph も含まれています！ まずはイメージを pull してください。6GB くらいあります。 docker pull container-registry.oracle.com/database/express:18.4.0-xe コンテナを起動するとデータベースの初回構築が始まります。これには数十分かかると思いますので、ゆっくりお待ち下さい。 docker run --name database \ -p 1521:1521 -e ORACLE_PWD=Welcome1 \ -v $HOME:/host-home \ container-registry.oracle.com/database/express:18.4.0-xe 以下のようなメッセージが出てきたら、データベースへの接続が可能です。 100% complete （略） ######################### DATABASE IS READY TO USE! ######################### 新しいコンソールを開いて、SQL クライアント（ sqlplus ）を用いて管理ユーザーとして接続します。 docker exec -it database sqlplus sys/Welcome1@xepdb1 as sysdba コンテナを再起動しても、同様に接続できることを確かめてください。 docker stop database docker start database ログはこちらで確認できます。 docker logs -f database Oracle Graph の有効化 さて、ここからいよいよ Oracle Graph の話になります。 Oracle Graph を有効化するためのパッチ（PL/SQL スクリプト）をこちらのサイトからダウンロードします。次のパッケージを選択すると、ライセンスへの同意と Oracle アカウントでのログインを要求されます。 Oracle Graph Client for PL/SQL Zip ファイル（ oracle-graph-plsql-21.4.0.zip ）がダウンロードできたらコンテナからアクセスできる適当な場所に展開してください。ここでは $HOME/oracle-graph としておきます。 cd $HOME/oracle-graph unzip oracle-graph-plsql-21.4.0.zip -d oracle-graph-plsql コンテナ上の SQL クライアントに接続します。 docker exec -it database sqlplus sys/Welcome1@xepdb1 as sysdba スクリプトを実行します。ここではホストの $HOME がコンテナの /host-home にマウントされています。 @/host-home/oracle-graph/oracle-graph-plsql/18c_and_below/opgremov.sql @/host-home/oracle-graph/oracle-graph-plsql/18c_and_below/catopg.sql exit ユーザーの作成 コンテナ上の SQL クライアントに接続します。 docker exec -it database sqlplus sys/Welcome1@xepdb1 as sysdba graphuser というデータベース・ユーザーを作成して必要な権限を与えます。 CREATE USER graphuser IDENTIFIED BY Welcome1 DEFAULT TABLESPACE users TEMPORARY TABLESPACE temp QUOTA UNLIMITED ON users; GRANT alter session , create procedure , create sequence , create session , create table , create trigger , create type , create view , graph_developer -- This role is required for using Graph Server TO graphuser; exit 新しいユーザーで接続できることを確認します。 docker exec -it database sqlplus graphuser/Welcome1@xepdb1 SQLcl の準備 sqlplus は PGQL を扱う機能がないため、PGQL プラグインが提供されている SQL クライアントの SQLcl を準備します。 SQLcl のプラグインを先と同様にこちらのサイトからダウンロードします。次のパッケージを選択すると、ライセンスへの同意と Oracle アカウントでのログインを要求されます。 PGQL Plugin for SQLcl ここでダウンロードした oracle-graph-sqlcl-plugin-21.4.0.zip と次に作成する Dockerfile を同じディレクトリに配置します。 vi Dockerfile Dockerfile FROM oraclelinux:7-slim RUN yum -y install unzip java-1.8.0-openjdk \ && yum clean all RUN curl -s https://download.oracle.com/otn_software/java/sqldeveloper/sqlcl-latest.zip > sqlcl-latest.zip RUN unzip sqlcl-latest.zip RUN chmod 755 sqlcl/bin/sql ADD oracle-graph-sqlcl-plugin-21.4.0.zip . RUN unzip oracle-graph-sqlcl-plugin-21.4.0.zip -d sqlcl/lib/ext \ && rm oracle-graph-sqlcl-plugin-21.4.0.zip ENV PATH=sqlcl/bin:$PATH CMD sql イメージをビルドします。 docker build -t sqlcl . sql コマンドでこのコンテナを都度実行できるように alias を設定します。 alias sql='docker run --rm -it sqlcl sql' 同じホスト上のコンテナで起動しているデータベースに接続します。Docker の動作している環境によっては host.docker.internal というホスト名が使えない場合がありますのでご注意ください。 sql graphuser/Welcome1@host.docker.internal:1521/xepdb1 グラフの作成 SQLcl を PGQL モードに切り替えできることを確認します。 SQL> pgql auto on PGQL Auto enabled for graph=[null], execute=[true], translate=[false] PGQL> PGQL クエリでグラフを作成します。 CREATE PROPERTY GRAPH graph1; グラフにふたつのノードとその間のエッジを追加します。クエリをペーストした際にうまく実行されない場合には、/（再実行のコマンド）を入力して実行できる場合があります。 INSERT INTO graph1 VERTEX v LABELS (PERSON) PROPERTIES (v.id = 'p1', v.NAME = 'Alice'); INSERT INTO graph1 VERTEX v LABELS (CAR) PROPERTIES (v.id = 'd1', v.BRAND = 'Toyota'); INSERT INTO graph1 EDGE e BETWEEN src AND dst LABELS (HAS) PROPERTIES (e.SINCE = 2017) FROM MATCH ( (src), (dst) ) ON graph1 WHERE src.id = 'p1' AND dst.id = 'd1'; COMMIT; グラフのパターンで「Alice の持っている車」を検索してみます。 SELECT p.NAME, LABEL(h), c.BRAND, h.SINCE FROM MATCH (p)-[h:HAS]->(c:CAR) ON graph1 WHERE p.NAME = 'Alice'; NAME LABEL(h) BRAND SINCE ________ ___________ _________ ________ Alice HAS Toyota 2017 全てのノードを削除すると接続されていたエッジも削除されます。 DELETE v FROM MATCH (v) ON graph1; COMMIT; グラフを削除します。 DROP PROPERTY GRAPH graph1; お疲れ様でした。今回の内容はここまでとしたいと思います。 この記事では Docker コンテナ上で Oracle Graph を構築して使い始めるための手順を紹介しました。Oracle Database 単体をグラフ・データベースとして使う方法があるということもご理解頂けたかと思います。 一方で、Oracle Graph の強みである、表データの宣言的な変換や高性能な Graph Server との連携など、Oracle Graph 自体についてはまだまだ紹介できていませんので、次回以降に記載していきたいと思います。

環境 ubuntu 20.04 GPU GeForce GTX 1060 ローカルのGPU設定 NVIDIA-SMI 460.39 Driver Version: 460.39 CUDA Version: 11.2 ことの経緯 tensorflow公式からGPUサポートのtensorflowイメージをpull run --gpus all ERRO[0000] error waiting for container: context canceled 確認 1. tensorflow公式からGPUサポートのtensorflowイメージをpull 公式に従ってタグlatest-gpuのイメージをプル docker pull tensorflow/tensorflow:latest-gpu 2. run sudo docker run --gpus all -it -v マウントしたいローカルのディレクトリ:コンテナ内のマウント先 --shm-size 8G --name コンテナの名前 tensorflow/tensorflow:latest-gpu 3. ERRO[0000] error waiting for container: context canceled docker: Error response from daemon: could not select device driver "" with capabilities: [[gpu]]. ERRO[0000] error waiting for container: context canceled うーーん、この 対策 nvidia-container-runtimeなどを入れる。 sudo apt-get install nvidia-container-runtime curl -s -L https://nvidia.github.io/nvidia-container-runtime/gpgkey | \ sudo apt-key add - distribution=$(. /etc/os-release;echo $ID$VERSION_ID) curl -s -L https://nvidia.github.io/nvidia-container-runtime/$distribution/nvidia-container-runtime.list | \ sudo tee /etc/apt/sources.list.d/nvidia-container-runtime.list sudo apt-get update sudo apt-get install nvidia-container-runtime service docker restart 気を取り直して sudo docker run --gpus all -it -v マウントしたいローカルのディレクトリ:コンテナ内のマウント先 --shm-size 8G --name コンテナの名前 tensorflow/tensorflow:latest-gpu 4. 確認 (コンテナ内で) nvidia-smi よし +-----------------------------------------------------------------------------+ | NVIDIA-SMI 460.39 Driver Version: 460.39 CUDA Version: 11.2 | |-------------------------------+----------------------+----------------------+ | GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | | | | MIG M. | |===============================+======================+======================| | 0 GeForce GTX 106... Off | 00000000:1D:00.0 On | N/A | | 27% 34C P8 9W / 120W | 242MiB / 6077MiB | 0% Default | | | | N/A | +-------------------------------+----------------------+----------------------+ +-----------------------------------------------------------------------------+ | Processes: | | GPU GI CI PID Type Process name GPU Memory | | ID ID Usage | |=============================================================================| +-----------------------------------------------------------------------------+

環境 ubuntu 20.04 GPU GeForce GTX 1060 ローカルのGPU設定 NVIDIA-SMI 460.39 Driver Version: 460.39 CUDA Version: 11.2 ことの経緯 tensorflow公式からGPUサポートのtensorflowイメージをpull run --gpus all ERRO[0000] error waiting for container: context canceled 確認 1. tensorflow公式からGPUサポートのtensorflowイメージをpull 公式に従ってタグlatest-gpuのイメージをプル docker pull tensorflow/tensorflow:latest-gpu 2. run sudo docker run --gpus all -it -v マウントしたいローカルのディレクトリ:コンテナ内のマウント先 --shm-size 8G --name コンテナの名前 tensorflow/tensorflow:latest-gpu 3. ERRO[0000] error waiting for container: context canceled docker: Error response from daemon: could not select device driver "" with capabilities: [[gpu]]. ERRO[0000] error waiting for container: context canceled うーーん、この 対策 nvidia-container-runtimeなどを入れる。 sudo apt-get install nvidia-container-runtime curl -s -L https://nvidia.github.io/nvidia-container-runtime/gpgkey | \ sudo apt-key add - distribution=$(. /etc/os-release;echo $ID$VERSION_ID) curl -s -L https://nvidia.github.io/nvidia-container-runtime/$distribution/nvidia-container-runtime.list | \ sudo tee /etc/apt/sources.list.d/nvidia-container-runtime.list sudo apt-get update sudo apt-get install nvidia-container-runtime service docker restart 気を取り直して sudo docker run --gpus all -it -v マウントしたいローカルのディレクトリ:コンテナ内のマウント先 --shm-size 8G --name コンテナの名前 tensorflow/tensorflow:latest-gpu 4. 確認 (コンテナ内で) nvidia-smi よし +-----------------------------------------------------------------------------+ | NVIDIA-SMI 460.39 Driver Version: 460.39 CUDA Version: 11.2 | |-------------------------------+----------------------+----------------------+ | GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | | | | MIG M. | |===============================+======================+======================| | 0 GeForce GTX 106... Off | 00000000:1D:00.0 On | N/A | | 27% 34C P8 9W / 120W | 242MiB / 6077MiB | 0% Default | | | | N/A | +-------------------------------+----------------------+----------------------+ +-----------------------------------------------------------------------------+ | Processes: | | GPU GI CI PID Type Process name GPU Memory | | ID ID Usage | |=============================================================================| +-----------------------------------------------------------------------------+

初投稿 [投稿の背景] 日頃、開発業務に携わり着々と業務をこなすと、知識の定着が主な目的でもありますが 学んだ内容を記録していきたいなと思って投稿を開始しました。 [目的] ここからタイトルの内容になりますが、 業務で開発等していると、サーバーとの通信を実装してデータのやり取りが発生したりすると思います。 そこで、HTTP/HTTPSの通信で、固定のレスポンスデータを返却できたら、 また、その上で自由にデータを書き換えることが出来たら。 以下のメリットがあると考え実行しました。 ・通信周りを学べる ・Dockerを学べる ※今回使用 ・デバッグがスムーズ [内容] Dockerのインストール Dcokerは、仮想環境構築してアプリケーションを開発できるソフトウェア DLサイト：https://hub.docker.com/editions/community/docker-ce-desktop-mac/ [手順] 以下、コマンドででdokcerがインストールされていることを確認する terminal $ docker -v [参考] ・ https://qiita.com/tomokei5634/items/7b1e7a121d5d7bc12116

初投稿 [投稿の背景] 日頃、開発業務に携わり着々と業務をこなすと、知識の定着が主な目的でもありますが 学んだ内容を記録していきたいなと思って投稿を開始しました。 [概要] タイトルの内容になりますが、 アプリ開発をしていると、 サーバー通信を実装したりすることもあると思いますが 今回は、HTTP通信で、固定のレスポンスデータを返却できたら、 また、その上で自由にデータを書き換えることが出来たら。良き良きと言う事で構築してみました。 <以下、メリット> ・Dockerを少しでも学べる 　※今回使用 ・通信周りを少しでも学べる ・デバッグの、工数削減 [作業] Dockerのインストール Dcokerは、仮想環境を構築してアプリケーションを開発できるソフトウェア。 仮想環境を作って、色々できるみたい。 今回は、ローカルサーバー構築のため、この子を使用してみたいと思います。 DLサイト：https://hub.docker.com/editions/community/docker-ce-desktop-mac/ [手順] 1, 上記DLサイトにて、ソフトを落してきてインストール！ 2, 以下、コマンドででDokcerバージョンが表示されればとりあえずOK！ terminal $ docker -v [参考] ・ https://qiita.com/tomokei5634/items/7b1e7a121d5d7bc12116

PocketMine-MPはDockerのコンテナ上で動かすことができます。 Docker とは開発者やシステム管理者が、コンテナでアプリケーションを 構築（build）、実行（run）、共有（share）するためのプラットフォームです。1 Dockerをインストール・セットアップしよう 上記のリンクからWindows/MacでのDocker Desktopがインストールできます。 インストールが終わった後に起動するとチュートリアルが始まります。 一通りやっておくと、この後の操作が理解しやすくなると思います。 注意 Windows Homeの場合はWSL2を有効にする必要があります。詳細は https://docs.docker.jp/docker-for-windows/install-windows-home.html を確認してください。 DockerでPocketMine-MPを動かしてみよう ここからが本題です。実際にPocketMine-MPをDocker上で動かしてみましょう。 PocketMine-MPは公式がDockerイメージを以下のリンクで公開しています。 英語版ですがそんなに難しい内容にはなっていないはずです。 1. Dockerイメージをダウンロードする 端末やWindowsターミナル上などでdocker pull pmmp/pocketmine-mpを実行してDockerダウンロードします。 2.プラグイン用のディレクトリとデータ用のディレクトリを作成する サーバーのデータを保持しておくディレクトリを決めて、その中にpluginsディレクトリとdataディレクトリを作ります。 3. コンテナを立ち上げる。 Windowsの場合 docker run -it -p 19132:19132/udp -v {上で決めたディレクトリへのパス}\\data:/data -v {上で決めたディレクトリへのパス}\\plugins:/plugins pmmp/pocketmine-mp を Mac/Linuxの場合は端末上で上のディレクトリを開いた状態で、 docker run -it -p 19132:19132/udp -v $PWD/data:/data -v $PWD/plugins:/plugins pmmp/pocketmine-mp を実行して起動します。 うまく起動するとサーバーのログが見れるはずです。 そのほかは通常のPocketMine-MPと同じように使うことができます。開けるポートが違うときには-pオプションでそれに対応するポートをしてしてください。 シナリオ: MySQLを使うプラグインを使用する この章ではdocker-composeを使用してDockerの要素をより使ってサーバーを構築することを考えます。特に、MySQLを使うプラグインと合わせて使うことを考えます。 1. docket-compose.ymlを記述する。 version: "3" services: pocketmine-server: image: pmmp/pocketmine-mp:latest # どのイメージを使うか、今回は最新版イメージを指定した。 ports: - "19132:19132/udp" depends_on: - mysql # mysqlサービスに対応していることを表す。 volumes: - 'C:\Devs\plugin-dev\MyChunkLand:/plugins' # 一例、絶対パスで実機:コンテナ上のディレクトリを対応させる。 - 'C:\Devs\plugin-dev\data:/data' mysql: image: mysql command: --default-authentication-plugin=mysql_native_password restart: always environment: MYSQL_ROOT_PASSWORD: password # rootユーザーのパスワードを指定する ports: - "3308:3306" # Docker上のmysqlコンテナのポート3306を実機上のポート3308に対応させる 上のようなファイルを記述しdocker-compose.ymlとして保存します。 2. docker-composeで立ち上げる そのディレクトリをカレントディレクトリにした状態で以下を実行すると、pocketmine-serverコンテナとmysqlコンテナを立ち上げられます。 docker-compose up 3. プラグインで設定をする この状態でいったんサーバーを停止してからプラグインの設定をします。 例えば、Ree-jp-minecraftさんのStackStorageプラグイン(GitHubリンク)では、以下のような設定にすると、対応ができます。 database: # mysql or sqlite type: mysql # MySQLを選択 # Edit these settings only if you choose "sqlite". sqlite: # The file name of the database in the plugin data folder. # You can also put an absolute path here. file: data.sqlite # Edit these settings only if you choose "mysql". mysql: host: mysql #ホストをコンテナ名に変更 # Avoid using the "root" user for security reasons. username: StackStorage #データベース内のユーザー名に対応 password: password #対応するパスワードへ # Database name schema: StackStorage # The maximum number of simultaneous SQL queries # Recommended: 1 for sqlite, 2 for MySQL. You may want to further increase this value if your MySQL connection is very slow. worker-limit: 1 ホストマシン側からはMySQLはポート3308からアクセスできます。 このプラグインであればデータベースにアクセスして以下のコマンドを実行することで一連の初期設定が終わります。 CREATE DATABASE StackStorage; CREATE USER StackStorage IDENTIFIED BY 'password'; GRANT ALL on StackStorage.* to StackStorage; ほかのプラグインについてもホストとユーザー、パスワードとスキーマをプラグインの指示に従い適切に設定することで動作させることができます。 まとめ PocketMine-MPはDockerコンテナ上で動作できる。 Dockerを使うとMySQLやその他の対応するサービスを一括で管理できる。 Dockerはいろいろなコンテナが対応しているのでサーバーを一括で管理するに役立ちます。この機会に一度お試しを！ https://docs.docker.jp/get-started/index.html#docker ↩

Dockerについて勉強しようと思ったので、メモがてらに書きます。 Dockerfileとは このファイルに書いた通りの環境が構築できるような感じです。 どんなイメージをベースにするのか、走らせたいコマンドはあるかなど、ここでちゃんと指定しないと上手く動かなかったり、コンテナごとの設定が変わったりします。 どうやって指定するのか 主に使われる命令コードは以下のリストです。 FROM: ベース（親）画像を指定します。 LABEL: メタデータを提供します。 メンテナ情報を含めるのに良い場所です。 ENV: 永続的な環境変数を設定します。 RUN: コマンドを実行してイメージレイヤを作成します。 パッケージをコンテナにインストールするために使用されます。 COPY: ファイルとディレクトリをコンテナにコピーします。 ADD: ファイルとディレクトリをコンテナにコピーします。 ローカルの.tarファイルをアンパックできます。 CMD: 実行中のコンテナにコマンドと引数を提供します。 パラメータは上書きできます。 CMDは1つだけです。 WORKDIR: あとに続く説明の作業ディレクトリを設定します。 ARG: ビルド時にDockerに渡す変数を定義します。 ENTRYPOINT: 実行中のコンテナにコマンドと引数を提供します。 引数は存続します。 EXPOSE: ポートを公開します。 VOLUME: 永続データにアクセスして保存するためのディレクトリマウントポイントを作成します。 docker buildを実行するとこのファイルで指定した命令通りにコンテナが作られます。

はじめに 普段 Serilog でログを出力しているので、ログの出力設定もSerilogの設定に依存しているため今まで気づきませんでしたが、.NET 6.0 のコンテナイメージの場合デフォルトのログの出力形式は取り回しのしやすさから JSON になっているようです。 Breaking Change: Default console logger format set to JSON この記事ではログの出力方法を標準の JSON 形式から別の形式に変更する方法について説明します。 標準で出力されるログ ASP.NET Coreのプロジェクトを.NET 6.0で作り、Dockerで実行すると次のようなログが出力されます。 {"EventId":60,"LogLevel":"Warning","Category":"Microsoft.AspNetCore.DataProtection.Repositories.FileSystemXmlRepository","Message":"Storing keys in a directory \u0027/root/.aspnet/DataProtection-Keys\u0027 that may not be persisted outside of the container. Protected data will be unavailable when container is destroyed.","State":{"Message":"Storing keys in a directory \u0027/root/.aspnet/DataProtection-Keys\u0027 that may not be persisted outside of the container. Protected data will be unavailable when container is destroyed.","path":"/root/.aspnet/DataProtection-Keys","{OriginalFormat}":"Storing keys in a directory \u0027{path}\u0027 that may not be persisted outside of the container. Protected data will be unavailable when container is destroyed."}} {"EventId":14,"LogLevel":"Information","Category":"Microsoft.Hosting.Lifetime","Message":"Now listening on: https://[::]:443","State":{"Message":"Now listening on: https://[::]:443","address":"https://[::]:443","{OriginalFormat}":"Now listening on: {address}"}} {"EventId":14,"LogLevel":"Information","Category":"Microsoft.Hosting.Lifetime","Message":"Now listening on: http://[::]:80","State":{"Message":"Now listening on: http://[::]:80","address":"http://[::]:80","{OriginalFormat}":"Now listening on: {address}"}} {"EventId":0,"LogLevel":"Information","Category":"Microsoft.Hosting.Lifetime","Message":"Application started. Press Ctrl\u002BC to shut down.","State":{"Message":"Application started. Press Ctrl\u002BC to shut down.","{OriginalFormat}":"Application started. Press Ctrl\u002BC to shut down."}} {"EventId":0,"LogLevel":"Information","Category":"Microsoft.Hosting.Lifetime","Message":"Hosting environment: Development","State":{"Message":"Hosting environment: Development","envName":"Development","{OriginalFormat}":"Hosting environment: {envName}"}} {"EventId":0,"LogLevel":"Information","Category":"Microsoft.Hosting.Lifetime","Message":"Content root path: /app/","State":{"Message":"Content root path: /app/","contentRoot":"/app/","{OriginalFormat}":"Content root path: {contentRoot}"}} ログ形式の変更 実行時は何を設定するのでもなく JSON 形式で出てくれるのはうれしいのですが、Visual Studio でデバックするときなどは人が読みやすい形式で出力される方が望ましいです。 通常のアプリケーションの場合、次のようにすると appsettings.json で出力形式を変更できますが、Docker で動作するアプリケーションの場合は ASP.NET Core の標準の Dockerfile の設定で Logging__Console__FormatterName は json で上書きされるためこの設定は無視されます。 ログ形式の変更については下記のドキュメントを参照してください。 appsettings.json(標準の出力) { "Logging": { "LogLevel": { "Default": "Information", "Microsoft.AspNetCore": "Warning" }, "Console": { "FormatterName": "simple" } }, "AllowedHosts": "*" } 通常のアプリの場合、上記の設定をすると次のようにシンプルなログが出力されます。 info: Microsoft.Hosting.Lifetime[14] Now listening on: https://localhost:7215 info: Microsoft.Hosting.Lifetime[14] Now listening on: http://localhost:5215 info: Microsoft.Hosting.Lifetime[0] Application started. Press Ctrl+C to shut down. info: Microsoft.Hosting.Lifetime[0] Hosting environment: Development 今まで通り simple で出力したい場合は、Dockerfile でさらに上書きするか、コンテナ実行時に環境変数で上書きする必要があります。 Dockerfileでログ設定を上書きする例 FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS base ENV Logging__Console__FormatterName=simple WORKDIR /app EXPOSE 80 EXPOSE 443 FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build WORKDIR /src # ...略... Dockerfile に設定してしまうと、運用環境でも json ではなく simple でログが出力されてしまいます。docker-compose が利用できるのであれば実行時の環境変数に設定して開発時のみ simple で出力したほうが良いでしょう。さらにいえば、docker-compose.yml よりも、docker-compose.override.yml で設定したほうがより望ましいでしょう。 docker-compose.override.ymlでログ設定を上書きする例 version: '3.4' services: webapplication25: environment: - ASPNETCORE_ENVIRONMENT=Development - ASPNETCORE_URLS=https://+:443;http://+:80 - Logging__Console__FormatterName=simple ports: - "80" - "443" volumes: - ${APPDATA}/Microsoft/UserSecrets:/root/.microsoft/usersecrets:ro - ${APPDATA}/ASP.NET/Https:/root/.aspnet/https:ro おわりに .NET 6.0 になってコンテナサイズのさらなる縮小など、よりコンテナ環境に最適化された修正が行われています。 詳しくは下記のページを参照してください。

はじめに この記事は、NTTコムウェア Advent Calendar 2021 4日目の記事です。 NTT コムウェア 1 年目の東です。 この記事では Dockerfile における技術的負債の中でも、Self-Admitted Technical Debt (SATD)と呼ばれる開発者によって認知されている技術的負債についてまとめます。 この記事から得られる知見によって、Dockerfile にはどのような技術的負債があるかを知っていただき、技術的負債の少ない Dockerfile を作成する足がかりとなれば幸いです。 技術的負債とは 技術的負債とは、場当たり的な実装を借金することに見立てて作られた比喩表現です。 技術的負債は借金と同じで、開発当初（借金の借入当初）は改修（返済）が容易かもしれませんが、開発が進むにつれ、影響箇所が増えることによってどんどん改修が困難になっていきます。 そのため、技術的負債を作らない、または早めに返済してしまうことが重要になってくるのです。 Self-Admitted Technical Debt (SATD) 技術的負債の中でも開発者が技術的負債であると認識しているものに関しては、Self-Admitted Technical Debt (SATD) と呼ばれます。 では、開発者はなぜ認識しているにもかかわらず、技術的負債を生んでしまうのでしょうか。 その答えとして、以下のような原因が考えられます。 納期に間に合わせるために開発を急がなければならない コードを書く知識が足りていないため、最適な実装方法を知らない 直前の仕様変更による準備不足 この記事を読んでいる方の中にも、上記のような理由のため、最善ではないと分かっていながらも次善的な実装を施し、技術的負債を混入させたことがあるという経験がある方は多いのではないでしょうか。 これらの技術的負債を生む要因の中でも「知識不足」に関しては、どのような部分が技術的負債になりやすいかや、類似する技術的負債に関する見識を広げることで、技術的負債を回避できるのではないかと考えます。 SATD の判定方法 前項で SATD は「開発者自身」が認識している技術的負債であると説明しました。 それでは、開発者以外が SATD であると判断するにはどうすればよいでしょうか。 コードに記述されたコメントを見ればよいのです。 多くの場合、次善的な実装をする際にはコード内にTODOやFIXMEなどの文字列と一緒にコメントで「この部分のコードには問題がある」という旨が記されています。 そのため、ソースコード内のコメントを読むことで、SATD が検出できます。 Dockerfile における SATD 今回は SATD の中でも Dockerfile における SATD にはどのようなものがあるかを紹介したいと思います。 Docker は 2013 年頃に開発された比較的新しいプラットフォームであり、Docker に精通している開発者が他のプラットフォームに比べて少ないと考えられることから、Docker イメージを構築するにあたり記述する Dockerfile にも多くの SATD が存在すると推測できます。 以下では、Dockerfile の SATD を体系的に分類し、それぞれの SATD の特徴を簡単に説明します。 コード例に関しては、実在する SATD の内容を参考に作成した架空のコードです。 Dockerfile の保守を困難にする恐れのある SATD 次善策による実装に関する SATD より最適な手法があると分かっていながら、時間的要因などで、次善策を採用している SATD です。 TODOコメントとして書かれていることが多いです。 # TODO: 特定の環境でyum autoremoveを行うと、filesystemまで消えるバグがあるため、手動で削除する。解決策は調査。 RUN yum remove packagex 処理の欠如に関する SATD コンテナ内部で必要な処理の実装が未実装であることについて言及している SATD です。 この SATD は実装していないことが致命的な機能ではなく、未実装でも問題が少ない付属的な機能に多いです。 # TODO: submojuleはshallow cloneした方がいいかもしれないから調査する RUN git submodule update --init --recursive ベースイメージに関する SATD ベースとしているイメージ自体にバグがあることに関する言及やベースイメージの変更を求める SATD です。 Docker ではベースイメージとして既存のイメージを継承できる機構が備わっています。そのため、開発者自身が開発している Dockerfile に問題は含まれていないものの、継承元に問題が含まれているというパターンが存在します。 # issueが解決されたらバージョンをあげる FROM sampleimage:1.2 バージョンに関する SATD パッケージマネージャでダウンロードするソフトウェアやツールのバージョン固定を促す SATD です。 バージョン固定に関してはDocker のベストプラクティスでも言及されており、パッケージの予期せぬ変更によるビルドの失敗を防ぐためにバージョンを固定するべきだと言われています。 # TODO: バージョンを固定する RUN npm install sample テストに関する SATD 真正確認に関する SATD コンテナ内で利用するバイナリファイルをダウンロードした際に、そのバイナリファイルのハッシュ値が正しいかどうかを PGP や sha256sum などで確認することを真正確認と呼びます。 その真正確認の不足に言及した SATD です。 この真正確認は中間者攻撃を防ぐために行われ、セキュリティ面を担保するために、Docker の公式イメージなどではよく行われています。 # TODO: sha256の値を検証し、検証できたらURLの末尾に.sha256を追加する RUN wget -O sample.tgz https://example.com/oss/sample.tar.gz テストを行うための改良に関する SATD テスト手法の改善に関する SATD です。 テスト自体の改善ではなく、テストを効率的に行うための改善に言及した SATD になっています。 # TODO: 1ファイルで複数のコンテナを立ち上げているが、テストにしか必要ないものが多いので、分離する FROM sample1 RUN yum ... FROM sample2 COPY /build / バグに関する SATD バグ回避のための強引な措置に関する SATD コンテナ内部で使用するソフトウェアやパッケージにバグが含まれていた場合に、それらのバグに対する回避策を実行している旨を記した SATD です。 中にはかなり強引な改変を行ってバグを回避している例もあるため、このような SATD が存在するイメージをベースイメージとして扱う場合は注意が必要です。 # FIXME: sampleのバージョンを5.1にするとビルドが落ちるので、治るまで5.0を指定しておく RUN pip install sample==5.0 将来的なバグに関する SATD 現在は顕在化していないものの、将来的に発生する可能性があるバグに言及した SATD です。 コンテナ内部で使用しているパッケージが後方互換性のないアップデートを行うことにより、現状しようしているコマンドが使用できなくなりバグとして現れます。 この SATD はあくまで現状は問題になっていないため、対応が後回しにされがちです。 # バージョンが期限切れになるとURLを変えなければならないかも RUN curl -OL https://example.com/oss/{VERSION}/sample.tar.gz Docker のベストプラクティスに反した設計に関する SATD イメージサイズ削減に関する SATD Docker のベストプラクティスとしてイメージサイズは極力小さくすることが良いとされています。 そのため、イメージのサイズ削減を要求する SATD が存在します。 例えば、Docker ではRUN命令を分けて書くと、その分層が増え、イメージサイズも大きくなるため、RUN命令で実行する shell コマンドは極力一まとめにすることを推奨されています。 また、この SATD もコンテナの実行には直接影響を与えることが少ないため、対応が後回しにされがちです。 # TODO: 不要なファイルを削除する 開発の特定プロセスにおける問題に関する SATD デプロイに関する SATD デプロイの際に起こり得る問題に言及した SATD です。 本番環境用にイメージを使用する際の注意喚起を行っている例がありました。 # このconfigを本番環境で使わないでください CMD ["server", "-dev"] Dockerfile 自体のレビューに関する SATD Dockerfile 自体のレビューを他の開発者に求めている SATD です。 この SATD では、現状の実装方法が最適かどうか開発者自身には判断がつかないため、他の開発者にレビューを求めている状況になっています。 # 書き方が正しいか自信がないので、レビューをお願いします。 おわりに 本記事では、Dockerfile における SATD について紹介しました。この記事を読んで少しでも技術的負債に関する見識が広がったり、今後の Dockerfile の開発に役立てていただいたりしていただければ幸いです。 以上でこの記事を締めたいと思います。 最後まで読んでいただき、ありがとうございました。 コンテナ仮想化技術における Self-Admitted Technical Debt の調査