初めに 　この記事は、自分用に作成したPython分析環境を共有するために書いています。Pythonで分析する際は、テーブルデータや画像、自然言語等が主な対象データになると思いますが、今回作成したDockerfileは、Conda、OpenCV、MeCabをインストールする構成にしたので、色々な分析のBaselineにすることが可能です。（自然言語処理をしない場合はMeCab部分のコードを消す等してください。） 　次の章から、作成した環境について説明をしていきますが、Docker等の単語の意味をここでは説明しません。Qiita には良質な解説記事が多くありますので、基本的な単語については、そちらを参考にしてください。 環境 　検証した環境を以下に示します。仮想環境には WSL2 ではなく、VirtualBox を使いました。WSL2 は別のマシンで環境構築した際に苦戦した思い出があるので、今回は VirtualBox + PowerShell で実施しています。 ・Windows 10 Pro 64bit ・Docker Desktop 4.0.0 (67817) (Download page) ・Docker Engine 20.10.8 ・Docker-compose v2.0.0-rc.2 Docker Desktop for Windows を使っていますが、場合によっては有料となっているため、企業が利用する場合等は注意ください。以下は ITmedia の記事です。 Docker Desktopが有料化へ　従業員数250人未満・年間売り上げ1000万ドル未満の組織などは引き続き無料 Docker インストールはこのあたりを参照ください。インストーラーが少し重いのでダウンロードに多少時間がかかります。（私の場合20分程度） WindowsでDocker環境を試してみる フォルダ構成 　Buildする際のフォルダ構成を以下に示します。３つのフォルダ（input / output / notebook）は、分析の際に .ipynbファイルやデータを置く場所です。Image内にこれらのフォルダを含める必要がない（Build の際には使わない）ため、.dockerignore に３つのフォルダ名を記載しています。また、docker-compose.yml に書いてある通り、このフォルダはマウントされるため、Build 完了後に起動する Jupyterlab からこのフォルダが見えるようになります。そのため、Windows とのやり取りはここで行うことが可能です。 Container name/ (ここは何でもOK) 　┠ input/ 　┠ output/ 　┠ notebook/ 　┠ .dockerignore 　┠ clean-layer.sh 　┠ docker-compose.yml 　┠ Dockerfile 　┠ requirements_conda.txt 　┠ requirements_pip.txt 　これら一式を 私のGithub に Upload したので、欲しい人はダウンロードしてご活用ください。 各ファイルの説明 　ここから各ファイルの内容について、要点を絞って解説していきます。 　まずは、docker-compose.yml からです。これは、以下のサイトを参考に作成しました。フォルダ構成等も大変参考になりました。 Dockerでデータ分析環境を手軽に作る方法 　やっていることを簡単に言うと、Image を Build して、最後の行に書かれている command を実行しています。この形で書いておくことによって、毎回長い docker run のコマンドをたたく必要がなく、覚えやすいコマンドで実行が出来るようになります。 docker-compose.yml version: "2.3" services: jupyter: build: . volumes: - .:/tmp/working working_dir: /tmp/working ports: - 8888:8888 command: jupyter lab --ip=0.0.0.0 --allow-root --no-browser ・build: .：実行した場所にあるDockerfileを実行します。 ・volumes: .:/tmp/working：実行した場所をマウントします。 ・ports: 8888:8888：Localhost:8888 をDocker のポート8888 に転送します。さらに、Jupyter側がポート8888（デフォルト）で待っているので、Localhost:8888 にアクセスすることで、Jupyter に繋がるようになります。 　GPUを使いたい場合は、build と同じ階層に runtime: nvidia を追加します。ここの書き方は docker-compose.yml の冒頭に記載している version に左右されることに注意ください。 　次は、clean-layer.sh です。これは、Kaggle公式のGithub と同じものです。Docker では、RUN コマンド等を実行する度に Layer が作成され、RUN を書けば書くほど最終的に出来上がる Image が重くなります。そのため、多くの人は１つの RUN コマンドに多くのコマンド（apt-get/pip等）を書いていると思います。しかし、RUN の最後にゴミを削除するコマンド（clean-layer.sh）を実行すれば、最終的な Image が重くなりません（どこまでかは未検証ですが・・・）。RUN を複数に分けることは、可読性向上に繋がるため、この記事では clean-layer.sh を挟む実装を採用しています。 clean-layer.sh #!/bin/bash # # This scripts should be called at the end of each RUN command # in the Dockerfiles. # # Each RUN command creates a new layer that is stored separately. # At the end of each command, we should ensure we clean up downloaded # archives and source files used to produce binary to reduce the size # of the layer. set -e set -x # Delete files that pip caches when installing a package. rm -rf /root/.cache/pip/* # Delete old downloaded archive files apt-get autoremove -y # Delete downloaded archive files apt-get clean # Ensures the current working directory won't be deleted cd /usr/local/src/ # Delete source files used for building binaries rm -rf /usr/local/src/* # Delete conda downloaded tarballs conda clean -y --tarballs 　最後に Dockerfile の解説を行います。こちらの書きっぷりも大変 Kaggle の Dockerfile が参考になりました。基本的には、Ubuntu20.04 + MiniConda + JupyterLab の環境であり、そこに Python のライブラリを入れているイメージです。 Dockerfile FROM ubuntu:20.04 ADD clean-layer.sh /tmp/clean-layer.sh COPY requirements_conda.txt ./ COPY requirements_pip.txt ./ ARG DEBIAN_FRONTEND=noninteractive # Make sure python version you want to use ENV PYTHON_MAJOR_VERSION=3 ENV PYTHON_MINOR_VERSION=7 ENV PATH="/root/miniconda3/bin:${PATH}" # Update and install necessary modules. RUN apt-get update && \ apt-get install -y git vim wget zip unzip curl make cmake && \ wget --quiet https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh && \ mkdir /root/.conda && \ bash Miniconda3-latest-Linux-x86_64.sh -b && \ rm -f Miniconda3-latest-Linux-x86_64.sh && \ chmod +x /tmp/clean-layer.sh && \ /tmp/clean-layer.sh # Install python RUN conda config --add channels conda-forge && \ conda config --add channels nvidia && \ conda config --add channels pytorch && \ conda config --add channels rapidsai && \ conda install --yes python=$PYTHON_MAJOR_VERSION.$PYTHON_MINOR_VERSION && \ apt-get install -y python3-pip && \ /tmp/clean-layer.sh # Install conda packages. # Conda can solve dependency problem, and running speed is fast more than pip packages. RUN conda install --yes --file requirements_conda.txt && \ /tmp/clean-layer.sh # Install pip packages. The packages, libsm6 libxrender1 are needed for opencv. RUN apt-get install -y libsm6 libxrender1 --fix-missing && \ pip3 install --no-cache-dir -r requirements_pip.txt && \ /tmp/clean-layer.sh # Install MeCab and NEologd dic (Japanese useful dictionary) RUN apt-get install -y sudo mecab mecab-ipadic libmecab-dev && \ git clone --depth 1 https://github.com/neologd/mecab-ipadic-neologd.git && \ chmod 777 ./mecab-ipadic-neologd/bin/install-mecab-ipadic-neologd && \ ./mecab-ipadic-neologd/bin/install-mecab-ipadic-neologd -y -n && \ cp /etc/mecabrc /usr/local/etc/mecabrc && \ /tmp/clean-layer.sh # Install jupyterlab and jupyter-kite (https://github.com/kiteco/jupyterlab-kite) RUN curl -sL https://deb.nodesource.com/setup_12.x |bash - && \ apt-get install -y --no-install-recommends nodejs && \ pip3 install --upgrade --no-cache-dir 'jupyterlab~=3.0' jupyterlab-git && \ wget --quiet https://linux.kite.com/dls/linux/current && \ pip3 install --upgrade --no-cache-dir jupyter-kite && \ jupyter labextension install "@kiteco/jupyterlab-kite" && \ /tmp/clean-layer.sh 　ベースイメージは Ubuntu20.04 にしていますが、GPU を使う場合は、ベースイメージを以下等に変更してください。 From nvidia/cuda:11.0.3-cudnn8-devel-ubuntu18.04 ・ARG DEBIAN_FRONTEND=noninteractive：cmake をインストールした際に、タイムゾーン選択が出て、Build が止まってしまうので、interactive dialogue が出ないようにしています。https://askubuntu.com/questions/909277/avoiding-user-interaction-with-tzdata-when-installing-certbot-in-a-docker-contai ・NEologd dic：正式名称は「mecab-ipadic-NEologd」。結構新しい単語もはいっている辞書で有用。https://github.com/neologd/mecab-ipadic-neologd ・jupyter-kite：Jupyter で Autocomplete を使えるようにします。https://github.com/kiteco/jupyterlab-kite Build 結果 コマンドは以下です。 docker-compose up --build または、 docker-compose build --no-cache docker-compose up 　--no-cache は、以下のエラーが Dockerfile 作成の試行錯誤中に何度か出たので、dockerでmysqlが立ち上がらなくなった。 を参考に追加しました。もし、ご自身で試行錯誤を実施した際にこのエラーが発生したら試してください。 failed to solve: rpc error: code = Unknown desc = failed to solve ... 　docker-compose up を実行すると Jupyter lab にアクセスする URL (http://127.0.0.1:8888/lab?token=...) が表示されるので、アクセスしてください。以下の画面が表示されます。 Git 連携 　今回、jupyterlab-git もインストールしているため、GitHub / GitLab との連携が可能です。試しに 私のGithub から clone してみます。まずは、clone するフォルダを配置する場所に移動します。今回は input の下に移動します。そして、以下画像の赤枠をクリックします。 　次に、Clone a Repository をクリックし、Clone したい Repository の URL (https://github.com/tt20171105/Machine-Learning 等）をコピペします。最後に CLONE をクリックすることで、input 直下に Machine-Learning フォルダが作成されます。これでご自身の Git を連携して修正して push したり、他の Repository を Clone してきて使ったりと便利になると思います。是非活用ください。

こんにちは。asatoです。 いま盛り上がっているTwitterスペース、気になるトピックを語っているTwitterスペースなどをかんたんに見つけられるspaces.bzというプロダクトを友人と運営しています。 特に開発初期段階なので、機能追加も頻繁に行っており、勇気と自信をもってプロダクトションへのデプロイを繰り返すためには、やはりテストの自動化が必要です。 spaces.bzはNuxt.js on Dockerで開発しており、今回はTestCafeでテスト自動化を導入しています。 TestCafeは、クロスブラウザに対応しており、テストコードも非常にわかりやすく書けるのが特徴です。 今回は「Headless Chromeでテストがしたいなー」というのと、テストコードにあまり馴染みのない友人と一緒に開発しているので「わかりやすいテストコード」だと良いなーと思っており、TestCafeはまさにピッタリでした。 この記事では、Nuxt on Dockerの環境でTestCafeを導入し、かんたんなテストを実行するところまでをまとめていきます！? 準備 Dockerfileとdocker-compose.ymlは以下のようなものを想定しています。 Dockerfile FROM node ENV HOME=/app \ HOST=0.0.0.0 WORKDIR ${HOME} COPY package.json ${HOME} COPY yarn.lock ${HOME} RUN yarn install COPY . ${HOME} EXPOSE 3000 CMD ["yarn", "dev"] docker-compose.yml version: "3" services: app: build: . volumes: - .:/app ports: - 3000:3000 TestCafeをインストールする TestCafeのパッケージをインストールします。今回はyarnを使っているので、 $ docker compose run app yarn add --dev testcafe です。☕ DockerfileでChromeをインストールする 今回はHeadless Chromeを使ってテストをしたいので、DockerコンテナでChromeを起動できる状態にしておく必要があります。 Dockerfile ...略... WORKDIR ${HOME} + + RUN wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | apt-key add - && \ + sh -c 'echo "deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main" >> /etc/apt/sources.list.d/google.list' && \ + apt-get update && \ + apt-get install -y google-chrome-stable && \ + apt-get install -yq fonts-noto-cjk COPY package.json ${HOME} COPY yarn.lock ${HOME} RUN yarn install COPY . ${HOME} ...略... ChromeのStable版と、日本語のフォントを表示するためにfonts-noto-cjkをインストールするように追記しました。 追記ができたらビルドして、Dockerイメージを作成しましょう。 $ docker compose build コマンドでTestCafeを起動できるようにする 次はコンテナでTestCafeを起動するコマンドの準備をしていきます。コンテナでyarn testのコマンドを実行したときにTestCafeが動くようにしましょう。 package.json ...略... "scripts": { "dev": "nuxt", "build": "nuxt build", "start": "nuxt start", - "generate": "nuxt generate" + "generage": "nuxt generate", + "test": "testcafe chrome:headless" }, ...略... testcafeの後ろにchrome:headlessを与えることでコンテナ内でHeadless Chromeを起動してテストしようとしてくれるんですね。 詳しくはこのへんに書いてます。 テストコードを書く いよいよテストコードです。まずはテスト用のディレクトリとファイルを作っておきましょう。 $ mkdir tests $ touch tests/sample.test.js テストの内容は「トップページにアクセスして、<h1>タグで"Hello World!!"と表示されていること」を検証してみましょう。 tests/sample.test.js import { Selector } from 'testcafe' fixture('Sample') .page('http://localhost:3000') test('トップページに<h1>タグで"Hello World!!"と表示されていること', async t => { await t .expect(Selector('h1').innerText).eql('Hello World!!') }) なんか読みやすそうじゃないですか？? fixtureでテスト全体に関する設定とかを行っています。このテストファイルはSampleって名前で、http://localhost:3000にアクセスするところから始まるよって感じです。 testでその後の操作や検証を書いていきます。testは1ファイルに複数書けます。 今回は.expect(A).eql(B)を使ってAとBが一緒であることを検証してみます。 Aの方はSelector('h1').innerTextと書きました。最初に現れたh1タグのinnerTextを取得してます。こんな感じで使い慣れたjavascriptさんも使えるんですね。 Bの方にHello World!!の文字列を書けば、「最初に現れたh1タグのinnerTextがHello World!!と一致すればテスト成功」となります。 ページを編集 このままテストを実行しても失敗するので、ページも編集しておきます。 TDDでやってみたい場合は、この時点で一度テストを実行してFailになることを確認してもOKです? pages/index.vue <template> <div> <h1>Hello World!!</h1> </div> </template> テストを実行する ではテストを実行しましょう・ｖ・ テストを実行する前にコンテナを起動させておきます。 $ docker compose up -d そして、execを使って起動したコンテナ内でTestCafeを実行します。 $ docker compose exec app yarn test tests/sample.test.js yarn run v1.22.5 $ testcafe chrome:headless tests/sample.test.js Running tests in: - Chrome 93.0.4577.82 / Linux 0.0 Sample ✓ トップページに<h1>タグで"Hello World!!"と表示されていること 1 passed (2s) Done in 31.12s. PASS!!出力も非常にわかりやすいですね！ まとめ この記事では、Nuxt on DockerにTestCafeを導入して、かんたんな自動テストを書いてみました。 自動テストがあれば、機能追加を頻繁に行なう環境でも勇気と自信を持ってデプロイできます！ そして、TestCafeはとても直感的なテストコードを書け、クロスブラウザにも対応しているすぐれものでした。 最後に、こんな自動テストを導入して開発しているspaces.bzもよろしくおねがいします！?

目的 開発マシン上のdockerで動作するrailsアプリケーションのdb接続を 踏み台サーバー経由でrdsに接続したい。 方法 前提 ◦踏み台サーバー ・エンドポイント ip: 12.12.12.12 ・pemファイル /Users/hoge/.ssh/hoge.pem ・接続ユーザー root ◦dbサーバー ・エンドポイント　private domain: hogehoge.internal (踏み台から見て) ・postgreSQL(portは、5432) ① macターミナルから以下コマンドを実行、SSHポートフォーワーディングを行う。 ssh -N -L 5434:hogehoge.internal:5432 -i /Users/hoge/.ssh/hoge.pem -p 22 root@12.12.12.12 ② database.ymlの行き先をmacの5434に設定。 database.yml host: host.docker.internal port: 5434 注) docker上で動くrailsアプリの場合なので、 localhost　でなく　host.docker.internal で指定 ③ rails サーバーを立ち上げる 正しくdbに接続されてることを確認。　 sshポートフォーワーディングとは sshポートフォーワーディングとは、sshコマンドのポート転送機能のこと。 sshコマンドは通常以下のように使用されるが、 ssh 10.10.10.10 ここに-L オプションをつけるとポートの転送先を設定できる。 例えば、 ssh -L ポート番号1:10.10.10.11:ポート番号2　10.10.10.10 これを実行すると、　 localhost:ポート番号1への接続が、10.10.10.10を経由して 10.10.10.11:ポート番号2に転送されるようになる。

Docker環境構築手順(コードや作業の細い解説は後で追加します。) Dockerfile作成 作業用ディレクトリを作りその配下にDockerfileを作る FROM ruby:2.6.5 RUN apt-get update -qq && apt-get install -y build-essential libpq-dev nodejs RUN mkdir /仮想環境でのディレクトリ名 WORKDIR /仮想環境でのディレクトリ名 COPY Gemfile /仮想環境でのディレクトリ名/Gemfile COPY Gemfile.lock /仮想環境でのディレクトリ名/Gemfile.lock RUN bundle install COPY . /仮想環境でのディレクトリ名 Gemfile作成 作業用ディレクトリを作りその配下にGemfileを作る source 'https://rubygems.org' gem 'rails', '6.0.0' Gemfile.lock作成 作業用ディレクトリを作りその配下にGemfile.lockを作る 中身は空 docker-compose.yml作成 作業用ディレクトリを作りその配下にdocker-compose.ymlを作る version: '3' services: web: build: . command: bash -c "rm -f tmp/pids/server.pid && bundle exec rails s -p 3000 -b '0.0.0.0'" volumes: - .:/subject_api - gem_data:/usr/local/bundle ports: - 3000:3000 tty: true stdin_open: true volumes: gem_data: 今回はデータベースを用いないAPI用なのでデータベースに関する記述は不要 作業用のディレクトリにてAPIモードのrails newを行う docker-compose run web rails new . --force —api 続いてbuildを立ち上げbundle installを行う docker-compose build 最後に仮想環境を立ち上げ起動できるか確認する docker-compose up

Docker の Volumes と Bind mounts について、何度読んでも意味が分からないのでまとめる。 docker run コマンドの -v (--volume) オプション リファレンス: https://docs.docker.com/engine/reference/run/#volume-shared-filesystems -v, --volume=[host-src:]container-dest[:] The host-src can either be an absolute path or a name value. If you supply an absolute path for the host-src, Docker bind-mounts to the path you specify. If you supply a name, Docker creates a named volume by that name. Docker 内のファイルを共有するには、Volumes と Bind mounts という二つの方法があるが、ややこしいことに、同じオプションで Volumes と Bind mounts という異なる機能を設定する。 A name value must start with an alphanumeric character, followed by a-z0-9, _ (underscore), . (period) or - (hyphen). An absolute path starts with a / (forward slash). host-src が英数文字から始まる時: Volumes host-src が / から始まる時: Bind mounts Volumes https://docs.docker.com/storage/volumes/ Volume を作る $ docker volume create my-vol Volume のリスト。いつの間にか出来ているボリュームの最後に先程作った物が出る。 $ docker volume ls DRIVER VOLUME NAME local 0ac8a1264245c3d065e045e06f5509691df967bba733deb49052548a04c39c5e ... local my-vol Volume の情報を見る。 $ docker volume inspect my-vol [ { "CreatedAt": "2021-09-16T01:41:33Z", "Driver": "local", "Labels": {}, "Mountpoint": "/var/lib/docker/volumes/my-vol/_data", "Name": "my-vol", "Options": {}, "Scope": "local" } ] これを見ると /var/lib/docker/volumes/my-vol/_data に実体がありそうだが、ホストが Mac だと見えない。この Volume をマウントして cont1 と名付けたコンテナを動かし、hello ファイルを作る。 $ docker run --name cont1 -v my-vol:/my-vol ubuntu \ bash -c 'echo "Hello, world!" > /my-vol/hello' Volume を別の cont2 と名付けたコンテナにマウントして中を見る。 $ docker run --name cont2 -v my-vol:/my-vol ubuntu \ cat /my-vol/hello Hello, world! ちゃんと共有されている。 Bind mounts https://docs.docker.com/storage/bind-mounts/ Volumes を使うとホストのどこにファイルが保存されるか分からない。ホスト側の位置を指定したい時は Bind mounts を使う。 例えば cont1 で先程作った ファイルをホストにバックアップする時はこうする。 $ mkdir backup $ docker run --rm --volumes-from cont1 -v $PWD/backup:/backup ubuntu \ tar cvf /backup/backup.tar /my-vol tar: Removing leading `/' from member names /my-vol/ /my-vol/hello 次の事が起こる。 --volumes-from cont1: cont1 コンテナに使われた Volumes を全部マウントする。 -v $PWD/backup:/backup: ホストの $PWD/backup をコンテナの /backup に bind mounts する。 tar cvf /backup/backup.tar /my-vol: コンテナの /my-vol を /backup/backup.tar にバックアップする。 コンテナの /backup/backup.tar の実体はホストの $PWD/backup:/backup/backup.tar なので、コマンドが終わるとホストに backup.tar が残る。 確認 $ tar tf backup/backup.tar my-vol/ my-vol/hello 後片付け $ docker container rm cont1 cont2 $ docker volume prune

どうも、エンジニアのハマベです。 仮想化の概念の理解って難しいな、と思ったので、まとめてみることにしました。 仮想化とは？ イメージとしては、大きなサーバー(PC本体)の中に小さな仮想のサーバーをつくり、そのなかで作業できるようにする。といった感じ。 メリット 本物のサーバー同様に扱えるし、テストに必要な環境などを自由に作成できる １台のPCに複数の環境を作ることが出来る まとめると、一つのハードウェアに必要な環境を集約できる、ということがメリットになる。環境ごとにハードウェアを用意すると、リソースをめいいっぱい使い切るのは難しいし運用も煩雑になってしまう。そこを解消できるのが、仮想化技術だ。 参考サイト： https://pfs.nifcloud.com/navi/beginner/virtualization.htm 仮想化3種類 ホストOS型 ホストOS(PC本体)の中に仮想化ソフトウェアをインストールし、その中にゲストOS(仮想PC)を作成する方式。 他２種に比べ、簡単に任意のOSで作成できるので、個人的な開発には向いている。 メリット 仮想化ソフトウェアが比較的扱いやすい ホストOSで実行中のアプリと並行して利用できる デメリット 他２種とくらべて動作が遅め ホストOSに負荷がかかると、動作が重くなってしまう イメージ画像 主なソフトウェア VirtualBox (Windows／Mac) WorkstationPlayer (Windows) 参考： https://qiita.com/Pentas/items/5f558deeddcfef814b3e ハイパーバイザー型 ホストOS型と違い、仮想化ソフトウェアを挟まず、直接ゲストOSをインストールする方式。 windows(10以降)の場合、「Hyper-V」というドライバが標準で入っており、使いやすい。本番環境(複数人での開発)向き。 メリット ホスト型に比べ、ハードウェアを直接制御するため、速度が速い デメリット 専用のドライバが必要で、ホスト型より少し難易度が高い 主なソフトウェア Hyper-V vSphereHypervisor KVM 参考： https://thinkit.co.jp/story/2012/10/17/3722 コンテナ型 他２種と異なり、ゲストOSをホストOS上にインストールしない。 「コンテナ」と呼ばれる仮想空間を作り、その中にアプリを構築する。コンテナはホストOSを使用して動作しているため、ゲストOSは必要ない。 メリット 起動が速く、処理が軽量で済む 比較的簡単に、環境をコピーできる コンテナの環境を合わせれば、どのサーバーでも確実にアプリが動作する デメリット カーネル(OSの中核)を共有するため、個別に変更できない コンテナ環境のベースとなるOSと異なるのシステムは動かせない 学習コストが比較的高め(新しい技術なので、情報がすくなめ) 主なソフトウェア Docker (正確にはオープンソース型プラットフォーム) Kubernetes (コンテナを管理するソフト？個別に調べた方がよさそう) 参考： https://licensecounter.jp/engineer-voice/blog/articles/20191101_post_31.html いかがだったでしょうか。 多分まだまだツッコミどころは多いと思われますが、ご指摘いただけると、とても嬉しいです。かなり喜びます。 以上、ご覧いただきありがとうございました。

概略 現在では、DevOpsのベスト・プラクティスを実現する重要な要素として、また、Infrastructure as Codeの観点からサービスをDockerで構築することがスタンダードとなっています。但し、今までは開発プラットフォームが主にWindowsだったため、中々コード化したインフラ構築の学習や開発が手元（ローカル環境）でできないのが現状でした。しかし、WSL2の登場によりWindwos上でもより本番環境に近いLinux環境でのサービスを試せるようになり、Dockerも試せるようになりました。 本章ではWSL2上に複数のDockerコンテナを起動し、動作を検証します。 環境イメージは下記の通りとなります。 本番環境に用意するべきサーバを全てローカルで起動する。 DBのデータ等、コンテナがダウンしても保存しておきたいデータはDockerホストにマウントし、永続化する。 全てのサーバはDocker及び、docker-composeでコンテナとして管理し操作する。 使用した環境 Windows11 Pro Insider Preview Intel Core i7-8650U 実装RAM 16.0 GB 目次 アーキテクト技術者・構成管理者・リモート開発者のためのローカル開発環境構築ガイド 2. Docker in WSL環境構築 2.1. Docker / docker compose インストール・初期設定 2.2. Docker環境構成検討 2.3. DockerによるMySQL(RDBMS)サーバ構築 2.4. DockerによるGo言語(AP)サーバ構築 2.5. DockerによるNginx(Web)サーバ構築 2.6. docker-composeによる簡易オーケストレーション 1.5. WSLでのsystemctl設定 < 前 2. Docker in WSL環境構築 次 > 2.1. Docker / docker compose インストール・初期設定