Dockerのサービスが起動した後に特定のコンテナを起動させたいと思ったので方法を検討してみました。MacかLinuxで動作すると思います。未検証ですがWIndowsの場合はWSL2のUbuntu上で設定すると動作するかもしれません。 参考 https://superuser.com/questions/1315050/run-shell-script-after-docker-daemon-starts スクリプトファイルを用意する 参考 https://leico.github.io/TechnicalNote/Mac/catalina-zsh $HOME/docker_startup.sh に以下の内容のファイルを用意する。 #!/bin/bash # 3分経過するか、dockerが起動するまでループする TMP_COUNT=0 until docker version > /dev/null 2>&1 || [ ${TMP_COUNT} -eq 180 ]; do sleep 1 TMP_COUNT=$((TMP_COUNT + 1)) done # dockerが起動した後に実行される処理 # # 例えば以下のコマンドを記述することでログイン時にportainerのコンテナを起動、もしくは作成する。 # if [ "$(docker ps -qf name=portainer -f status=exited)" ]; then # コンテナが既に作成済みの場合はstartで起動 docker start portainer elif [ ! "$(docker ps -aqf name=portainer)" ]; then # コンテナが無い場合は新しく作成 docker run \ --detach \ --publish 8000:8000 \ --publish 9000:9000 \ --name portainer \ --restart always \ --volume /var/run/docker.sock:/var/run/docker.sock \ --volume portainer_setting_data:/data \ portainer/portainer-ce fi # 上記で作成したコンテナとボリュームは下記のコマンドで削除可能 # docker stop $(docker ps -aqf "name=portainer") && docker rm $(docker ps -aqf "name=portainer") && docker volume rm portainer_setting_data ファイルに実行権限を持たせる 起動時に実行出来るように実行権限をもたせます。Permission deniedエラーが表示される場合は、700を705等にしてみてください。 chmod 700 $HOME/docker_startup.sh ログイン時に実行させる https://itiut.hatenablog.com/entry/2013/07/07/114143 UbuntuのGUIの場合は~/.profileに以下の内容を追記。他Linuxの場合は~/.bash_profileに追記、MacはCatalinaより新しいOSの場合、~/.zshrcに追記する。その他環境によってはログイン時に実行されるファイルが違うので注意して設定してください。 /bin/bash $HOME/docker_startup.sh

概要 起動したはずのコンテナが永遠にrestartingしているので、ログを追って何が起きているのかを調べる。 docker psの例 対処法 docker logs コマンド docker logs --tail 50 --follow --timestamps <コンテナ名> オプション --tail：ファイル末尾からの行数を指定 --follow：新たなログをストリーミング 参考

はじめに 自分はよく、「WSL2 + Docker + Laravel + React(or Vue)」環境で開発していて、動作が遅すぎて毎度イライラし、作業効率を大幅に下げていました。 シンプルにメモリのせいだと思い、メモリを増築・・・ しかし、それでも大差のない遅さ。 なんでだろうと思って色々調べたときに、対策したメモです。（Windows環境です。） Mac環境であれば、@ucan-labさんの https://qiita.com/ucan-lab/items/a88e2e5c2a79f2426163 をご参照ください。大変わかりやすいです。いつも大変お世話になっております・・・ ちなみに、ReactやVueとかの環境を作っている場合にもかなり効果的でした。 （npm run devとかするときですね。） 結論 「\\wsl$\Ubuntu-20.04\mnt\」配下に、プロジェクトを配置するのではなく、 「\\wsl$\Ubuntu-20.04\home\」配下に、プロジェクトを配置。 ※Ubuntuのバージョンは、良しなに・・・ つまり、 「¥¥wsl$\Ubuntu-20.04¥home¥」配下に、 Dockerfileとかdocker-componse.ymlがある場所で 「docker-compose up -d --build」とかをしてみる。 ということです。 内容 動作が遅くなっている理由として、 WindowsとLinuxのOSファイルシステム間でのファイル読み込みが遅くなっていることが原因です。 WSLがどういう構造で、どういうフォーマット形式で動作しているのかなどの確認をしたい場合には、 参考のリンクを参照ください。めちゃくちゃわかりやすいです、どちらも。 所感 ほんと、とんでもなく速くなっているので、なんでもっと早く気付かなかったのだろうと・・・ とにかく、「WSL2 + Docker + Laravel + React(or Vue)」などの環境で動作が遅いことを気にされている方は一読を。 参考 https://www.aska-ltd.jp/jp/blog/197 https://snyt45.com/posts/20210806/wsl2-multiple-linux-distribution/

PortainerはDocker上でportainerコンテナを作ってDocker全体を管理するタイプのツールです。 参考 https://qiita.com/polarbear08/items/931fe04ec228fad13092 https://stackoverflow.com/questions/394230/how-to-detect-the-os-from-a-bash-script 起動させるのがめんどくさいので自分用にちょっと便利にしたスクリプトを作成しました。(ただしwindowsは非対応) スクリプト内容 Docker起動後に以下の内容が記載されたファイルを実行することでPortainerを実行させます。 例えば.zprofileや.bash_profile等に/bin/sh ファイルパス.shといった感じに追記してターミナル起動時に起動させることが出来ます（起動したらブラウザを開く）。既に起動している場合はportainer running. URLが表示されるだけです。 portainerに設定した内容はDocker Volumeのportainer_setting_dataに格納されます。 ターミナル起動時毎に実行され、dockeとportainerrが起動しているか等を判定するので、ターミナルの起動時間が気になる人はcronとか使ったりして対応するか、このスクリプト自体使わない方が良いかもしれません。 #/bin/bash # コンソール表示用の環境変数 PORTAINER_URL=http://docker.local # ホスト側のポート番号 PORTAINER_PORT1=8000 PORTAINER_PORT2=9000 if [ "$(docker stats --no-stream)" ]; then if [ "$(docker ps -qf name=portainer -f status=running)" ]; then # portainer動作中 echo "portainer running. ${PORTAINER_URL}:${PORTAINER_PORT1}" elif [ "$(docker ps -qf name=portainer -f status=exited)" ]; then # portainerコンテナはあるが動作していない場合 docker start portainer echo "portainer start. ${PORTAINER_URL}:${PORTAINER_PORT2}" # URLを開く if [[ "$OSTYPE" == "linux-gnu"* ]]; then # Linux echo "open linux" xdg-open ${PORTAINER_URL}:${PORTAINER_PORT2} elif [[ "$OSTYPE" == "darwin"* ]]; then # Mac OSX open ${PORTAINER_URL}:${PORTAINER_PORT2} fi elif [ ! "$(docker ps -aqf name=portainer)" ]; then # portainerコンテナが存在していない場合 docker run \ --detach \ --publish ${PORTAINER_PORT1}:8000 \ --publish ${PORTAINER_PORT2}:9000 \ --name portainer \ --restart always \ --volume /var/run/docker.sock:/var/run/docker.sock \ --volume portainer_setting_data:/data \ portainer/portainer-ce echo "portainer create. ${PORTAINER_URL}:${PORTAINER_PORT2}" # URLを開く if [[ "$OSTYPE" == "linux-gnu"* ]]; then # Linux echo "open linux" xdg-open ${PORTAINER_URL}:${PORTAINER_PORT2} elif [[ "$OSTYPE" == "darwin"* ]]; then # Mac OSX open ${PORTAINER_URL}:${PORTAINER_PORT2} fi fi fi portainer削除 上記スクリプトのファイルを削除してから下記を実行することでコンテナとボリュームをそれぞれ削除出来ます。 コンテナを停止して削除 docker stop $(docker ps -aqf "name=portainer") && docker rm $(docker ps -aqf "name=portainer") 設定が入ったボリュームを削除 docker volume rm portainer_setting_data

想定環境 WSL2 on Windows11 with NVIDIA GPU Install WSL2 (Ubuntu) のインストール 参照: https://docs.microsoft.com/ja-jp/windows/wsl/install パワーシェル(管理者権限) wsl --install -d Ubuntu-20.04 イメージ置き場 C:\Users\iwatake\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu20.04onWindows_79rhkp1fndgsc\LocalState WindowsからWSLファイルへのアクセス \\wsl.localhost\Ubuntu-20.04 WSLからWindowsファイルへのアクセス /mnt/c/ WSLのGUIアプリを実行する場合、Windows側にX表示用アプリ (VcXsrvなど) は不要。だけど、Docker上のGUIアプリを実行する場合は必要っぽい VSCode Windows上のVSCodeにms-vscode-remote.vscode-remote-extensionpack をインストールしておく WSL上で、sudo apt install wget ca-certificates しておく NVIDIA CUDA in WSL のインストール (optional) NVIDIA Drivers for CUDA on WSLをインストール https://developer.nvidia.com/cuda/wsl/download 510.06_gameready_win11_win10-dch_64bit_international.exe 参考 https://docs.microsoft.com/ja-jp/windows/ai/directml/gpu-cuda-in-wsl Dockerのインストール 参考 https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/install-guide.html https://qiita.com/ksasaki/items/ee864abd74f95fea1efa#wsl-2-%E4%B8%8A%E3%81%AE-linux-%E3%81%B8%E3%81%AE-nvidia-container-toolkit-%E3%81%AE%E3%82%A4%E3%83%B3%E3%83%88%E3%83%BC%E3%83%AB WSL # Docker curl https://get.docker.com | sh sudo usermod -aG docker $USER # NVIDIA Container Toolkit (optional) distribution=$(. /etc/os-release;echo $ID$VERSION_ID) curl -s -L https://nvidia.github.io/nvidia-docker/gpgkey | sudo apt-key add - curl -s -L https://nvidia.github.io/nvidia-docker/$distribution/nvidia-docker.list | sudo tee /etc/apt/sources.list.d/nvidia-docker.list curl -s -L https://nvidia.github.io/libnvidia-container/experimental/$distribution/libnvidia-container-experimental.list | sudo tee /etc/apt/sources.list.d/libnvidia-container-experimental.list sudo apt-get update sudo apt-get install -y nvidia-docker2 sudo service docker restart sudo service docker start Docker よく使うコマンド 管理コマンド 基本 sudo service docker start # WSLの場合、毎回startが必要 # docker image ls docker images # docker container ls -a docker ps -a docker rm MY_CONTAINER_NAME docker rmi IMAGE_NAME 保存(コンテナからイメージ作成) docker commit MY_CONTAINER_NAME my_new_image_from_container docker save my_new_image_from_container -o my_new_image_from_container.tar イメージの取得 WSL docker pull ubuntu:20.04 イメージのビルド Dockerfile FROM ubuntu:20.04 RUN apt-get update && DEBIAN_FRONTEND=noninteractive apt-get install -y \ build-essential \ cmake \ curl \ git \ libopencv-dev \ nano WSL docker build ./ -t cpp_opencv_image # docker run --rm -it cpp_opencv_image コンテナの生成と起動 同じコンテナを使いたい場合 WSL # docker run -itd --name=MY_CONTAINER_NAME ubuntu:20.04 docker create -it --name=MY_CONTAINER_NAME ubuntu:20.04 docker start MY_CONTAINER_NAME docker exec -it MY_CONTAINER_NAME bash docker stop MY_CONTAINER_NAME メモ createでの-it 指定はコンテナの標準入出力、ターミナルの設定。docker attach MY_CONTAINER_NAME 用。また、これがないとstartしてもすぐに終了してしまう。 execでの-it は新規に作成するbashプロセス用の設定 1回だけ動かす(コンテナは毎回削除) WSL docker run --rm -it ubuntu:20.04 docker run --rm ubuntu:20.04 /bin/echo "Hello World" よく使うオプション WSL docker create -v /mnt/c/iwatake/devel:/root/devel -e DISPLAY="192.168.1.2:0" -e TZ=Asia/Tokyo -w /root/ -p 8888:8888 -it --name=MY_CONTAINER_NAME ubuntu:20.04 docker run --rm -v /mnt/c/iwatake/devel:/root/devel -e DISPLAY="192.168.1.2:0" -e TZ=Asia/Tokyo -w /root/ -p 8888:8888 -it ubuntu:20.04 Docker 例 TensorFlow + Jupyter WSL docker run -it --rm -v /mnt/c/iwatake/devel:/home/jovyan/devel -e DISPLAY="192.168.1.2:0" -p 8888:8888 jupyter/tensorflow-notebook NGC: TensorFlow + Jupyter WSL docker run --gpus all -it --rm -v /mnt/c/iwatake/devel:/workspace/devel -e DISPLAY="192.168.1.2:0" -p 8888:8888 nvcr.io/nvidia/tensorflow:21.11-tf2-py3 jupyter-lab train_mnist.ipynb # https://www.tensorflow.org/guide/gpu?hl=ja import tensorflow as tf print("Num GPUs Available: ", len(tf.config.experimental.list_physical_devices('GPU'))) mnist = tf.keras.datasets.mnist (x_train, y_train), (x_test, y_test) = mnist.load_data() x_train, x_test = x_train / 255.0, x_test / 255.0 # with tf.device('/CPU:0'): with tf.device('/GPU:0'): model = tf.keras.models.Sequential([ tf.keras.layers.Flatten(input_shape=(28, 28)), tf.keras.layers.Dense(128, activation='relu'), tf.keras.layers.Dropout(0.2), tf.keras.layers.Dense(10), tf.keras.layers.Softmax() ]) loss_fn = tf.keras.losses.SparseCategoricalCrossentropy(from_logits=True) model.compile(optimizer='adam', loss=loss_fn, metrics=['accuracy']) model.fit(x_train, y_train, epochs=5) model.evaluate(x_test, y_test, verbose=2) NGC: その他 WSL docker run --gpus all nvcr.io/nvidia/k8s/cuda-sample:nbody nbody -gpu -benchmark docker run --gpus all -it --rm -v /mnt/c/iwatake/devel/:/workspace/devel -e DISPLAY="192.168.1.2:0" nvcr.io/nvidia/tensorrt:21.11-py3 docker run --gpus all -it --rm -v /mnt/c/iwatake/devel/:/workspace/devel -e DISPLAY="192.168.1.2:0" nvcr.io/nvidia/cuda:11.4.2-devel-ubuntu20.04 メモ TensorRTはONNXモデル変換がうまくいかない (変換中に、GPU error during getBestTactic: xxx : invalid argument エラーが出てフリーズする)。けど、サンプルのmnixt.onnxは変換可能なので、モデル依存か? Docker その他 Docker内のワークスペースをVSCodeで開く Windows上でDocker Desktopを入れていたら、Remote Explorer -> Containersで開けるはず WSL内にdocker-ceをインストールしている場合、WSL上で、code . を開いてから、Remote Explorer -> Containersで開けるはず 開きたいコンテナを選んで、Attach Container。すると新Windowsが開くので、OpenFolder GUI出力について WSL2のGUIは何もしないでも出力される (Windows11の場合) WSL2 + DockerのGUIはX11フォワーディングが必要 DISPLAY環境変数を自分のIPアドレスに設定する Xサーバソフトが必要。vcxsrvか、MobaXterm 描画速度はどれも大差なかった (1280x720のcv::Matをcv::imshow, waitkeyした場合) VS2019(Windows11): 2.5 ms WSL2: 1.5ms WSL2 + Docker: 1.6m ※Windows10の時はもっと遅かった気がする WSL上で、TensorRT環境を整える CUDAはNGC環境で動いた だけど、TensorRTはNGC環境だと動かないので、しょうがないのでWSL上で直接構築する WSL上でもうまく動かなかった。。。 WSL上で、CUDAのインストール https://docs.nvidia.com/cuda/wsl-user-guide/index.html#ch03a-setting-up-cuda WSL wget https://developer.download.nvidia.com/compute/cuda/repos/wsl-ubuntu/x86_64/cuda-wsl-ubuntu.pin sudo mv cuda-wsl-ubuntu.pin /etc/apt/preferences.d/cuda-repository-pin-600 wget https://developer.download.nvidia.com/compute/cuda/11.4.0/local_installers/cuda-repo-wsl-ubuntu-11-4-local_11.4.0-1_amd64.deb sudo dpkg -i cuda-repo-wsl-ubuntu-11-4-local_11.4.0-1_amd64.deb sudo apt-key add /var/cuda-repo-wsl-ubuntu-11-4-local/7fa2af80.pub sudo apt-get update sudo apt-get -y install cuda sudo ldconfig 下記エラー発生時 /sbin/ldconfig.real: /usr/lib/wsl/lib/libcuda.so.1 is not a symbolic link 参考: https://github.com/microsoft/WSL/issues/5548#issuecomment-912495487 パワーシェルを管理者として開き、 パワーシェルとWSL wsl -e /bin/bash cd /mnt/c/Windows/System32/lxss/lib ln -s libcuda.so.1.1 libcuda.so.1 ln -s libcuda.so.1.1 libcuda.so 下記を毎回実行するか、~/.bashrc に追加する WSL export PATH="/usr/local/cuda/bin:$PATH" export LD_LIBRARY_PATH="/usr/local/cuda/lib64:$LD_LIBRARY_PATH" WSL上で、cuDNNのインストール https://docs.nvidia.com/deeplearning/cudnn/install-guide/index.html#install-linux https://developer.nvidia.com/rdp/cudnn-download ↑のバージョンの場合、 https://developer.nvidia.com/compute/machine-learning/cudnn/secure/8.2.4/11.4_20210831/cudnn-11.4-linux-x64-v8.2.4.15.tgz WSL tar -xvf cudnn-11.4-linux-x64-v8.2.4.15.tgz sudo cp cuda/include/cudnn*.h /usr/local/cuda/include sudo cp -P cuda/lib64/libcudnn* /usr/local/cuda/lib64 sudo chmod a+r /usr/local/cuda/include/cudnn*.h /usr/local/cuda/lib64/libcudnn* WSL2上で、TensorRTのインストール https://docs.nvidia.com/deeplearning/tensorrt/install-guide/index.html https://developer.nvidia.com/nvidia-tensorrt-download TensorRT-8.2.1.8.Linux.x86_64-gnu.cuda-11.4.cudnn8.2.tar.gz WSL version="8.2.1.8" arch=$(uname -m) cuda="cuda-11.4" cudnn="cudnn8.2" tar xzvf TensorRT-${version}.Linux.${arch}-gnu.${cuda}.${cudnn}.tar.gz 下記を毎回実行するか、~/.bashrc に追加する WSL version="8.2.1.8" export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:~/TensorRT-${version}/lib export TensorRT_ROOT=~/TensorRT-${version} WSL2上で、USB接続のWebCameraを使う (usbipd使用バージョン) 参照 https://github.com/rpasek/usbip-wsl2-instructions https://devblogs.microsoft.com/commandline/connecting-usb-devices-to-wsl/ https://zenn.dev/pinto0309/articles/c3014043502245 一度だけやればよいこと usbipdをWindows上でインストール https://github.com/dorssel/usbipd-win/releases/download/v1.2.0/usbipd-win_1.2.0.msi カーネルとカーネルモジュールのビルド WSL sudo apt install build-essential flex bison libssl-dev libelf-dev libncurses-dev autoconf libudev-dev libtool uname -r # 5.10.16.3-microsoft-standard-WSL2 sudo git clone https://github.com/microsoft/WSL2-Linux-Kernel.git /usr/src/5.10.16.3-microsoft-standard cd /usr/src/5.10.16.3-microsoft-standard sudo git checkout linux-msft-wsl-5.10.16.3 sudo cp /proc/config.gz config.gz sudo gunzip config.gz sudo mv config .config sudo make menuconfig ### ↓↓↓ 変更内容 Device Drivers->USB support[*] Device Drivers->USB support->Support for Host-side USB[M] Device Drivers->USB support->Enable USB persist by default[*] Device Drivers->USB support->USB Modem (CDC ACM) support[M] Device Drivers->USB support->USB Mass Storage support[M] Device Drivers->USB support->USB/IP support[M] Device Drivers->USB support->VHCI hcd[M] Device Drivers->USB support->VHCI hcd->Number of ports per USB/IP virtual host controller(8) Device Drivers->USB support->Number of USB/IP virtual host controllers(1) Device Drivers->USB support->USB Serial Converter support[M] Device Drivers->USB support->USB Serial Converter support->USB FTDI Single Port Serial Driver[M] Device Drivers->USB support->USB Physical Layer drivers->NOP USB Transceiver Driver[M] Device Drivers->Network device support->USB Network Adapters[M] Device Drivers->Network device support->USB Network Adapters->[Deselect everything you don't care about] Device Drivers->Network device support->USB Network Adapters->Multi-purpose USB Networking Framework[M] Device Drivers->Network device support->USB Network Adapters->CDC Ethernet support (smart devices such as cable modems)[M] Device Drivers->Network device support->USB Network Adapters->Multi-purpose USB Networking Framework->Host for RNDIS and ActiveSync devices[M] Device Drivers > Multimedia support[*] Device Drivers > Multimedia support > Media drivers > Media USB Adapters[*] Device Drivers > Multimedia support > Media drivers > Media USB Adapters > USB Video Class (UVC) [M] Device Drivers > Multimedia support > Media drivers > Media USB Adapters > USB Video Class (UVC) > UVC input events device support [*] ### ↑↑↑ 変更内容 sudo make -j 12 && sudo make modules_install -j 12 && sudo make install -j 12 sudo cp /usr/src/5.10.16.3-microsoft-standard/vmlinux /mnt/c/Users/iwatake/. ビルドしたカーネルを使用するように設定する C/Users/iwatake/.wslconfig [WSL2] kernel=C:\\Users\\iwatake\\vmlinux 一度wsl --shutdown する WSL上でUSB/IP用のユーザースペースツールのインストール (この手順は不要かも) WSL sudo apt install linux-tools-5.4.0-77-generic hwdata sudo visudo ### ↓↓↓ 変更内容 # Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin" Defaults secure_path="/usr/lib/linux-tools/5.4.0-77-generic:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin" ### ↑↑↑ 変更内容 一度wsl --shutdown する 毎回必要なこと 必要なモジュールをロードする。/dev/video* を使えるようにする sudo modprobe usbcore sudo modprobe usb-common sudo modprobe hid-generic sudo modprobe hid sudo modprobe usbnet sudo modprobe cdc_ether sudo modprobe rndis_host sudo modprobe usbserial sudo modprobe usb-storage sudo modprobe cdc-acm sudo modprobe ftdi_sio sudo modprobe usbip-core sudo modprobe vhci-hcd sudo modprobe uvcvideo # sudo modprobe videobuf2-v4l2 # sudo modprobe videobuf2-memops # sudo modprobe videobuf2-common # sudo modprobe videobuf2-vmalloc sudo chmod 777 /dev/video* PowerShell(管理者) usbipd wsl list #PS C:\Users\iwatake> usbipd wsl list # BUSID DEVICE STATE # 1-8 USB 入力デバイス, WinUsb デバイス Not attached # 1-12 USB 入力デバイス Not attached # 1-13 USB オーディオ デバイス, USB ビデオ デバイス Not attached # 2-2 USB 入力デバイス Not attached usbipd wsl attach --busid 1-13 usbipd wsl detach --busid 1-13 WSL2 + Docker上で、USB接続のカメラを使う WSL2上でUSBカメラが使用できる状態で、--device=/dev/video0:/dev/video0 オプションをつけてコンテナを作る docker create -v /mnt/c/iwatake/devel:/root/devel -e DISPLAY="192.168.1.2:0" --device=/dev/video0:/dev/video0 -it --name=cpp_opencv cpp_opencv_image

方法 Docker Desktopを使っている場合、下記の通りExperimental FeaturesのUse the new Virtualization frameworkを有効にしてDockerを再起動します。 免責 私の環境では常時160%以上CPUを使用してたコンテナが常時60%程度になりました。この機能はまだ実験的機能で本記事の内容で安定性と効果を保証するものではありません。

方法 Docker Desktopを使っている場合、下記の通りExperimental FeaturesのUse the new Virtualization frameworkを有効にしてDockerを再起動します。 免責 私の環境では常時160%以上CPUを使用してたコンテナが常時60%程度になりました。この機能はまだ実験的機能で本記事の内容で安定性と効果を保証するものではありません。 雑感 筐体の温度やバッテリ持ちも改善すると思う。安定性は特に変わらない。 M1チップって書いてるけど、Intelチップでも改善する気がする。あとで比較してみる。

Docker Desktopの代替案を探していたところMultipassがかなり良い感じだったので構築方法を記載しておきます。 Multipassとは Multipassは手軽・高速にUbuntu環境を作成する仮想環境で、Linux, Windows, Macで動作します。 ホスト環境 この内容を実施するとホストのMacには以下の影響があります。 Docker Desktopを使わない。 Mac上でdockerコマンドを使うとMultipass上のdockerが使用されます。 Ubuntu構築用にCPU,メモリ,ストレージ等のリソースが必要です。 Homebrewでmultipass, docker, docker-composeをインストールします。 ~/.sshディレクトリのconfigファイルに必要な記述を追記します。 ~/.sshディレクトリにsshファイルを作成します。 Ubuntuにホームディレクトリをマウントします（任意）。 Docker Desktopのように各種アクセス先はlocalhostではなく任意の名前.localでアクセスが出来るようになります。localhostと切り分けができるので個人的にはこちらの方が好みです。 MultipassがHypreKitを利用しているので他の仮想化アプリケーションは無くても構いません。（任意で別の仮想化アプリケーションを利用する方法もあるようです） 参考 https://medium.com/@gourneau_38759/docker-engine-with-multipass-on-macos-dc44ff09ffb2 必要なパッケージをインストール # もし、homebrewでdocker desktop及びdockerがインストールしてある場合は以下を実行で一旦削除 # brew uninstall --force docker docker-machine docker-compose brew install multipass docker docker-compose SSHファイル作成 multipass_dockerという任意の名前でSSHファイルを作成します。 your_email@example.comの箇所は必ず書き換えてください。メールアドレスである必要はありません。 ssh key gen https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent ssh-keygen -t rsa -b 4096 -C "your_email@example.com" -f ~/.ssh/multipass_docker # your_email@example.comは以下のようにuuidgenを使ってランダムな文字列を使っても良い # ssh-keygen -t rsa -b 4096 -C "$(uuidgen)" -f ~/.ssh/multipass_docker chmod 600 ~/.ssh/multipass_docker chmod 600 ~/.ssh/multipass_docker.pub yamlファイル作成 Ubuntu構成用に以下のコマンドをターミナルで入力してファイルを作成する。 # 作成した.pubファイルを変数に読み込む AUTHORIZED_KEYS=$(cat ~/.ssh/multipass_docker.pub ) # ヒアドキュメントでファイルを作成する cat > ./multipass_docker.yaml << _EOF_ --- locale: en_US.UTF8 timezone: Asia/Tokyo package_upgrade: true users: - name: ubuntu sudo: ALL=(ALL) NOPASSWD:ALL ssh-authorized-keys: - ${AUTHORIZED_KEYS} packages: - docker - avahi-daemon - apt-transport-https - ca-certificates - curl - gnupg - lsb-release runcmd: - sudo curl -fsSL https://get.docker.com | sudo bash - sudo systemctl enable docker - sudo systemctl enable -s HUP ssh - sudo groupadd docker - sudo usermod -aG docker ubuntu _EOF_ 構築 以下の様式でMultipassを使ったUbuntuを構築します。 multipass launch -c CPU -m メモリ量 -d ストレージ容量 -n 任意の名前 20.04 --cloud-init ./multipass_docker.yaml 以下のコマンドでUbuntuを構築します。今回はdockerという名前のマシンで作成しており、これ以降docker.localで直接アクセス出来るようになります。 dockerという名前は任意ですので、他の名前でもかまいません。その際はアクセス先が任意の名前.localになります。 multipass launch -c 2 -m 4G -d 40G -n docker 20.04 --cloud-init ./multipass_docker.yaml 構築できたか確認 # SSH接続をする。 # 念の為、以下を実行してログイン記録を削除。 ssh-keygen -R docker.local # sshファイルを使用してMultipassのインスタンスにログイン ssh -i ~/.ssh/multipass_docker ubuntu@docker.local # Multipassのインスタンスにログイン出来たら以下を実行してdockerがインストールされているか確認 docker info # 確認出来たらインスタンスから出る exit # SSH接続が出来ることが確認出来たら構成用に使用したyamlファイルは不要になるので削除する。 rm ./multipass_docker.yaml # 設定内容の確認 multipass info docker # 一覧表 multipass ls ~/.ssh/configファイルに追記 ssh ubuntu@docker.localコマンドでログイン出来るように~/.ssh/configファイルに以下を追記します。無い場合は新しく作成しましょう。 Host docker.local HostName docker.local IdentityFile ~/.ssh/multipass_docker User ubuntu Port 22 ログイン出来るか確認 multipass shell multipassコマンドで以下を実行することでログイン出来ます。 multipass shell docker # 確認出来たらインスタンスから出る exit sshでログイン # 念の為、以下を実行してログイン記録を削除。 ssh-keygen -R docker.local # ubuntuにログイン ssh ubuntu@docker.local # ログイン出来ることを確認出来たらインスタンスから出る。 exit .zshrcに追記 環境変数DOCKER_HOSTにUbuntuのアクセス先を記述することで、ホスト側でのdockerコマンドはUbuntuのものを使うように設定できます。.zshrcの末尾にでも追記しておくことで、ログイン時に設定されるようにしておきましょう。 # multipass docker export DOCKER_HOST="ssh://ubuntu@docker.local" [任意]ホームディレクトリをMultipass上にマウントする 作業しやすいようにホームディレクトリをUbuntu上にマウントします。 1回マウントしたらホストを再起動してもマウントし続けます。 # ホームをUbuntu上の同じ名前の階層（/Users/ユーザ名）にマウントする multipass mount ${HOME} docker:${HOME} # アンマウント # multipass unmount docker:${HOME} この作業は任意ですが、していない場合、docker上でDockerfileやdocker-compose.yamlと同階層のファイルをマウントしようとしてもMultipassの内部しか見えていない状態なので以下のようなエラーになります。 user@mac docker % docker-compose up [+] Running 1/0 ⠿ Container docker-xxxx-1 Created 0.0s Attaching to docker-xxxx-1 Error response from daemon: invalid mount config for type "bind": bind source path does not exist: /Users/*** テスト nginxを使ってみる docker run --name nginx_test -d -p 8080:80 nginx # 以下で削除 # docker stop $(docker ps -aqf "name=nginx_test") # docker rm $(docker ps -aqf "name=nginx_test") アクセス この場合URLはhttp://docker.local:8080です。 外部からのアクセス 外部からアクセスするにはmultipass lsもしくはmultipass info dockerでIPv4項目を参照しましょう。 削除 multipassの削除は、deleteで一次削除、purgeで完全削除の２段階です。 deleteでゴミ箱に入れて、purgeでゴミ箱を空にする感じです。 # 削除は以下 multipass delete docker multipass purge

dockerはじめました報告です笑 試しにクジラをターミナルで出現させました。 $ docker run docker/whalesay cowsay "hello world"

はじめに Docker ComposeでDB(MySQLとPostgreSQL)とAdminer(DB管理ツール)を起動して、NestJSアプリケーションと接続してみました。 本記事はその手順のメモです。 実装 実装は大きく分けてコンテナの起動とNestJSアプリケーションの接続の2つです。 コンテナの起動 MySQL, PostgreSQL, AdminerのDockerイメージは公式のものを使用します。 これらをDocker Composeで一発で起動できるように、docker-compose.ymlを以下のように記述します。 docker-compose.yml version: "3.8" services: mysql: image: mysql:8.0.23 command: --default-authentication-plugin=mysql_native_password restart: always environment: MYSQL_ROOT_PASSWORD: example ports: - 3306:3306 postgres: image: postgres:13.1 restart: always environment: POSTGRES_PASSWORD: example ports: - 5432:5432 adminer: image: adminer restart: always ports: - 8080:8080 docker-compose upを実行し、localhost::8080にアクセスするとAdminerが開きます。 以下の情報を入力するとMySQLとPostgreSQLにログインすることができます。 データベース種類：MySQL (PostgreSQL) サーバ：mysql (postgres) ユーザ名：root (postgres) パスワード：example MySQLとPostgresQLでデータベースnest-eventsを作成します。 NestJSアプリケーションの接続 MySQLとの接続についてのみ記述します。 アプリケーションからDBを操作するにあたり、ORMとしてTypeORMを使用します。 そのため、まずは以下のパッケージをインストールします。 npm install @nestjs/typeorm typeorm mysql 次に、app.module.ts内でTypeOrmの設定を行います。 databaseに前項で作成したnest-events、entitiesにEventを記述することで、DBとEntityの紐付け(マッピング)を行います。 app.module.ts @Module({ imports: [ TypeOrmModule.forRoot({ type: 'mysql', host: '127.0.0.1', port: 3306, username: 'root', password: 'example', database: 'nest-events', entities: [Event], synchronize: true }), ], controllers: [AppController, EventsController], providers: [AppService], }) EntityであるEventは以下のように記述します。 各カラムにデコレータを付加することで、属性を指定しています。 @PrimaryGeneratedColumn()を付加すると、MySQLでいうAUTO_INCREMENTなカラムとなります。 event.entity.ts import { Column, Entity, PrimaryGeneratedColumn } from 'typeorm'; @Entity() export class Event { @PrimaryGeneratedColumn() id: number; @Column() name: string; @Column() description: string; @Column() when: Date; @Column() address: string; } app.module.tsでsynchronize: trueを指定していたため、npm run start:devでアプリケーションを起動すると、以下のように自動的にテーブルが作られます。 参考資料

準備 dockerのbuildxを使ってビルドします。まずはビルダを作成して起動します。 docker buildx create --name mybuilder docker buildx use mybuilder docker buildx inspect --bootstrap ビルド・push ビルドしてpushします。--platformにはビルドしたいプラットフォームを指定します。ここではarm64とamd64を指定しています。 docker buildx build \ --platform linux/arm64,linux/amd64 \ -t {ご所望のDockerHubレジストリ(user_name/registry_name)} \ --push .

課題 DockerコンテナからJupyter Labを起動する際に、自身の嗜好にあったカスタム設定が既に反映されていてほしい。 解決策 カスタム設定を記述した<plugin_name>.jupyterlab-settingsファイルを生成する。 Dockerfile内でホストマシン上の<plugin_name>.jupyterlab-settingsのパスをイメージのファイルシステム上のパスにCOPYする。 具体例 Monokai++を設定に反映する。 Monokai++の設定を書き込むファイル名を特定する。 .jupyterlab-settingsの<plugin_name>を特定する。 適当にJupyter Labを起動し、上部メニューからSettings >>> Advanced Settings Editor >>> Themeを選択する。 System Defaultsの//Themeの下にある// @jupyterlab/apputils-extension:themesのthemesが<plugin_name>にあたる。 themes.jupyter-lab-settingsを生成する。 Dockerfileが存在するパスと同じ場所に、themes.jupyter-lab-settingsというファイルを生成する。 themes.jupyter-lab-settingsに以下の内容を書き込む。 { "theme": "Monokai++" } Dockerfileを修正する。 Dockerfile内のJupyter Labや拡張機能をinstallした後に、以下の内容を書き込む。 # make directory RUN mkdir -p /root/.jupyter/lab/user-settings/@jupyterlab/apputils-extension/ # copy setting files COPY themes.jupyterlab-settings /root/.jupyter/lab/user-settings/@jupyterlab/apputils-extension/ コード自動整形がファイル保存と同時に行われるよう設定に反映したい。 コード自動整形の設定を書き込むファイル名を特定する。 .jupyterlab-settingsの<plugin_name>を特定する。 適当にJupyter Labを起動し、上部メニューからSettings >>> Advanced Settings Editor >>> Jupyter Lab Code Formatterを選択する。 System Defaultsの//Jupyterlab Code Formatterの下にある// @ryantam626/jupyterlab_code_formatter:settingsのsettingsが<plugin_name>にあたる。 settings.jupyter-lab-settingsを生成する。 Dockerfileが存在するパスと同じ場所に、settings.jupyter-lab-settingsというファイルを生成する。 settings.jupyter-lab-settingsに以下の内容を書き込む。 { "formatOnSave": true } Dockerfileを修正する。 Dockerfile内のJupyter Labや拡張機能をinstallした後に、以下の内容を書き込む。 # make directory RUN mkdir -p /root/.jupyter/lab/user-settings/@ryantam626/jupyterlab_code_formatter/ # copy setting files COPY settings.jupyterlab-settings /root/.jupyter/lab/user-settings/@ryantam626/jupyterlab_code_formatter/ 左括弧を押下すると自動で右括弧で閉じられるよう設定に反映したい。 括弧の設定を書き込むファイル名を特定する。 .jupyterlab-settingsの<plugin_name>を特定する。 適当にJupyter Labを起動し、上部メニューからSettings >>> Advanced Settings Editor >>> Notebookを選択する。 System Defaultsの//Notebookの下にある// @jupyterlab/notebook-extension:trackerのtrackerが<plugin_name>にあたる。 tracker.jupyter-lab-settingsを生成する。 Dockerfileが存在するパスと同じ場所に、tracker.jupyter-lab-settingsというファイルを生成する。 tracker.jupyter-lab-settingsに以下の内容を書き込む。 { "codeCellConfig": { "autoClosingBrackets": true } } Dockerfileを修正する。 Dockerfile内のJupyter Labや拡張機能をinstallした後に、以下の内容を書き込む。 # make directory RUN mkdir -p /root/.jupyter/lab/user-settings/@jupyterlab/notebook-extension/ # copy setting files COPY tracker.jupyterlab-settings /root/.jupyter/lab/user-settings/@jupyterlab/notebook-extension/ 参考 Dockerfile リファレンス - COPY Advanced Usage - JupyterLab User Settings Directory オレオレJupyterlab環境をDockerで作った - オレオレ設定にするには

はじめに RailsアプリをDocker上で構築し、CircleCIを用いて、RSpecによる自動テスト、またHerokuへの自動デプロイの仕組みを実現していく。 環境 フレームワーク : Rails テストフレームワーク : RSpec データベース : MySQL コンテナ : Docker(Docker Compose) CI/CDツール : CircleCI サーバー : Heroku 前提 GitHub、Herokuに登録済み Docker、Docker Composeをインストール済み 参考 山浦清透さんのDocker超入門講座 合併版 | ゼロから実践する4時間のフルコースという動画を参考にさせていただく。 Docker環境でRailsアプリを作成 作業用ディレクトリを用意し、必要なファイルを作成する。 今回はqiita-railsというディレクトリ内で作業していく。 qiita-rails/ ├ src/ └ Gemfile ├ docker-compose.yml └ Dockerfile Gemfile source 'https://rubygems.org' gem 'rails', '~> 6.1.4', '>= 6.1.4.1' docker-compose.yml version: '3' services: db: image: mysql:8.0 command: --default-authentication-plugin=mysql_native_password volumes: - ./src/db/mysql_data:/var/lib/mysql environment: MYSQL_ROOT_PASSWORD: password web: build: . command: bundle exec rails s -p 3000 -b '0.0.0.0' volumes: - ./src:/app ports: - "3000:3000" environment: RAILS_ENV: development depends_on: - db Dockerfile FROM ruby:2.7 RUN curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add - \ && echo "deb https://dl.yarnpkg.com/debian/ stable main" | tee /etc/apt/sources.list.d/yarn.list \ && apt-get update -qq \ && apt-get install -y nodejs yarn \ && apt-get -y install imagemagick WORKDIR /app COPY ./src /app RUN bundle config --local set path 'vendor/bundle' \ && bundle install 作業用ディレクトリに移動後、Railsアプリを作成。 $ docker-compose run rails new . --force --database=mysql Gemfileが更新されたのでコンテナのイメージをビルドし直す。 $ docker-compose build database.ymlのdefaultのpasswordとhostを設定。 src/config/database.yml . . . default: &default adapter: mysql2 encoding: utf8mb4 pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %> username: root password: password host: db . . . データベースを作成する。 $ docker-compose run web rails db:create コンテナを起動する。 $ docker-compose up ブラウザでlocalhost:3000を開き、以下の画面が表示されていれば成功。 Herokuの設定 Heroku、Heroku Container Registryにログインし、アプリを作成。 $ heroku login $ heroku container:login $ heroku create qiita-rails MySQL用のアドオンを追加する(Herokuにクレジットカードの登録が必要）。 $ heroku addons:create cleardb:ignite -a qiita-rails database.ymlのproductionを設定する。 src/config/database.yml . . . production: <<: *default database: <%= ENV['APP_DATABASE'] %> username: <%= ENV['APP_DATABASE_USERNAME'] %> password: <%= ENV['APP_DATABASE_PASSWORD'] %> host: <%= ENV['APP_DATABASE_HOST'] %> $ heroku config -a qiita-rails でこれらの環境変数を確認し $ heroku config:add でそれぞれ設定していく。 作業用ディレクトリに、start.shを追加し、Dockerfileを編集する。 qiita-rails/ ├ src/ ├ docker-compose.yml ├ Dockerfile 　　　　　　　　　　　　　　　　　　　　└ start.sh start.sh #!/bin/sh if [ "${RAILS_ENV}" = "production" ] then bundle exec rails assets:precompile fi bundle exec rails s -p ${PORT:-3000} -b 0.0.0.0 Dockerfile FROM ruby:2.7 ENV RAILS_ENV=production RUN curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add - \ && echo "deb https://dl.yarnpkg.com/debian/ stable main" | tee /etc/apt/sources.list.d/yarn.list \ && apt-get update -qq \ && apt-get install -y nodejs yarn \ && apt-get -y install imagemagick WORKDIR /app COPY ./src /app RUN bundle config --local set path 'vendor/bundle' \ && bundle install COPY start.sh /start.sh RUN chmod 744 /start.sh CMD ["sh", "/start.sh"] Herokuに環境変数を追加する。 $ heroku config:add RAILS_SERVE_STATIC_FILES='true' -a qiita-rails CircleCIでCI/CDを構築 事前にGitHubにリポジトリを作成しておく。 GemfileにRSpecを追加する。 Gemfile group :development, :test do gem 'rspec-rails' end Gemfileが更新されたのでコンテナのイメージをビルドし直す。 $ docker-compose build 下記ののコマンドでwebコンテナの中に入り、bashが使えるようにるので、 $ docker-compose exec web bash RSpecをインストールする。 $ rails generate rspec:install CircleCIにGitHubでログインする。 作業用ディレクトリに、.circleciディレクトリ、config.ymlを追加する。 qiita-rails/ ├ src/ ├ docker-compose.yml ├ Dockerfile 　　　　　　　　　　　　　　　　　　　　├ start.sh 　　　　　　　　　　　　　　　　　　　　└ .circleci/ └ config.yml .circleci/config.yml version: 2.1 orbs: ruby: circleci/ruby@1.1.2 heroku: circleci/heroku@1.2.3 jobs: build: docker: - image: circleci/ruby:2.7 working_directory: ~/qiita-rails/src steps: - checkout: path: ~/qiita-rails - ruby/install-deps test: docker: - image: circleci/ruby:2.7-node - image: circleci/mysql:5.5 environment: MYSQL_ROOT_PASSWORD: password MYSQL_DATABASE: app_test MYSQL_USER: root environment: BUNDLE_JOBS: "3" BUNDLE_RETRY: "3" APP_DATABASE_HOST: "127.0.0.1" RAILS_ENV: test working_directory: ~/qiita-rails/src steps: - checkout: path: ~/qiita-rails - ruby/install-deps - run: name: Database setup command: bundle exec rails db:migrate - run: name: yarn Install command: yarn install - run: name: webpack command: bundle exec bin/webpack - run: name: Rspec command: bundle exec rspec deploy: docker: - image: circleci/ruby:2.7 steps: - checkout - setup_remote_docker: version: 19.03.13 - heroku/install - run: name: heroku login command: heroku container:login - run: name: push docker image command: heroku container:push web -a $HEROKU_APP_NAME - run: name: release docker image command: heroku container:release web -a $HEROKU_APP_NAME - run: name: database setup command: heroku run bundle exec rake db:migrate RAILS_ENV=production -a $HEROKU_APP_NAME workflows: version: 2 build_test_and_deploy: jobs: - build - test: requires: - build - deploy: requires: - test filters: branches: only: main database.ymlのtestを設定する。 src/config/database.yml . . . test: <<: *default database: app_test host: <%= ENV.fetch('APP_DATABASE_HOST') { 'db' } %> . . . $ heroku config:add でmaster.keyの値をHerokuの環境変数RAILS_MASTER_KEYとして追加する。 CicleCIのサイトにログイン後、Projects→qiita-rails→Project Settings→Environment Variables→Add Environment Variablesと進み、 Name:HEROKU_APP_NAME,　Value:qiita-rails Name:HEROKU_API_KEY,　Value:(HerokuのサイトでAccount settingsから確認) を追加する。 最後に これで、gitにpush後GitHub上でCreate pull requestを行うと自動でRSpecによるテストが開始し、それが成功するとMerge pull requestが押せるようになり、Merge pull requestを実行するとまた自動でRSpecによるテストが開始し、それが成功すると自動でHerokuにデプロイされるという仕組みを実現することができた。 いずれサーバー環境をHerokuからAWSに切り替えようと考えている。