コンテナ内に入る ①docker ps もしくは ②docker-compose ps でコンテナIDを確かめる。 ① $ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 7d323ba6b1b8 mysql:5.7 "docker-entrypoint.s…" 51 minutes ago Up 51 minutes 3306/tcp, 33060/tcp hogelog_db_1 $ docker exec -it < コンテナID > sh　（shもしくはbash） $ docker exec -it 7d323ba6b1b8 sh ② % docker-compose ps Name Command State Ports -------------------------------------------------------------------------------------------- hogelog_db_1 docker-entrypoint.sh mysqld Up 0.0.0.0:4306->3306/tcp, 33060/tcp $ docker exec -it < コンテナNAME > sh　（shもしくはbash） $ docker exec -it hogelog_db_1 sh コンテナ内に入れたら ＃ mysql -u root -p Enter password: パスワードを要求されるので、docker-compose.ymlに記述してあるパスワードを入力する。 mysql> 接続完了。 mysql> exit Bye

動機 CIを回していると、定期的にデプロイされた画面を確認してスモークテストを行い結果を保存しておいたいということがあります。 そこで Docker ベースで Puppetter を実行できるようにしました。 実行時に作成されるスクリーンショットはホスト側にマウントしたディレクトリに作成されるようにします。 この時、Puppeteer の Running Puppeteer in Docker だとハマるポイントがあったので、そのメモです。 結論 Running Puppeteer in Docker のやり方（pptruser で実行）だと、screenshot を撮るときにパーミッションのエラーがでる。マウントするディレクトリを事前に作成することでエラーを回避できる デフォルトの root ユーザで実行する場合は、screenshot を撮るときにエラーが出ない。ただし、--no-sandbox オプションを利用する必要がある 利用バージョン Docker: 20.10 Node: 12.22.1 google-chrome: 90.0.4430.93 Puppeteer: 9.0.0 流れ Puppeteer の Docker image の作成 作成したイメージを利用して Puppeteer を実行する ドキュメントの方法（pptruser）で実行する場合 1. Docker image の作成 Running Puppeteer in Docker に従って、Dockerfile を作成します。 FROM node:12-slim # Install latest chrome dev package and fonts to support major charsets (Chinese, Japanese, Arabic, Hebrew, Thai and a few others) # Note: this installs the necessary libs to make the bundled version of Chromium that Puppeteer # installs, work. RUN apt-get update \ && apt-get install -y wget gnupg \ && 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 fonts-ipafont-gothic fonts-wqy-zenhei fonts-thai-tlwg fonts-kacst fonts-freefont-ttf libxss1 \ --no-install-recommends \ && rm -rf /var/lib/apt/lists/* # Install puppeteer so it's available in the container. RUN npm i puppeteer \ # Add user so we don't need --no-sandbox. # same layer as npm install to keep re-chowned files from using up several hundred MBs more space && groupadd -r pptruser && useradd -r -g pptruser -G audio,video pptruser \ && mkdir -p /home/pptruser/Downloads \ && chown -R pptruser:pptruser /home/pptruser \ && chown -R pptruser:pptruser /node_modules # Run everything after as non-privileged user. USER pptruser CMD ["google-chrome-stable"] 2. Puppeteer のスクリプトの作成 example.js const puppeteer = require('puppeteer') const screenshot = 'example.png'; (async () => { const browser = await puppeteer.launch({ headless: true, args: [ '--disable-dev-shm-usage' ] }) try { const page = await browser.newPage() await page.goto('https://www.amazon.co.jp/') await page.type('#twotabsearchtextbox', 'nyan cat') await page.click('#nav-search-submit-button') await page.waitForNavigation() await page.screenshot({ path: screenshot, fullPage: true }) console.log('See screenshot: ' + screenshot) } catch (e) { console.error(e) } finally { browser.close() } })() 3. 実行する 以下のコマンドを実行することで、./screenshot/ 以下にファイルが作成されます。 docker build -t puppeteer-chrome-linux-pptr . mkdir -p screenshot chmod 777 screenshot docker run -i --init --rm --cap-add=SYS_ADMIN \ --shm-size=256m \ -w /screenshot/ \ -v "$(pwd)/tmp:/screenshot" \ --name puppeteer-chrome puppeteer-chrome-linux-pptr \ node -e "`cat example.js`" mkdir tmp chmod 777 tmp がないと、page.screenshot() の呼び出し時に以下のエラーで怒られます。 [Error: EACCES: permission denied, open '/screenshot/example.png'] { errno: -13, code: 'EACCES', syscall: 'open', path: '/screenshot/example.png' } マウントするディレクトリが存在しない場合、Docker はディレクトリを作成してくれます。しかし、作成されるディレクトリは root が所有者で 755 が権限になっています。 コンテナ内の pptruser では書き込むことができないため、エラーになります。 root ユーザで実行する場合 1. Docker image の作成 pptruser 周りの設定は消して、Dockerfile を作成します。 FROM node:12-slim # Install latest chrome dev package and fonts to support major charsets (Chinese, Japanese, Arabic, Hebrew, Thai and a few others) # Note: this installs the necessary libs to make the bundled version of Chromium that Puppeteer # installs, work. RUN apt-get update \ && apt-get install -y wget gnupg \ && 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 fonts-ipafont-gothic fonts-wqy-zenhei fonts-thai-tlwg fonts-kacst fonts-freefont-ttf libxss1 \ --no-install-recommends \ && rm -rf /var/lib/apt/lists/* # Install puppeteer so it's available in the container. RUN npm i puppeteer CMD ["google-chrome-stable"] イメージをビルドします。 docker build -t puppeteer-chrome-linux . 2. Puppeteer のスクリプトの作成 example.js const puppeteer = require('puppeteer') const screenshot = 'example.png'; (async () => { const browser = await puppeteer.launch({ headless: true, args: [ '--no-sandbox', '--disable-setuid-sandbox', '--disable-dev-shm-usage' ] }) try { const page = await browser.newPage() await page.goto('https://www.amazon.co.jp/') await page.type('#twotabsearchtextbox', 'nyan cat') await page.click('#nav-search-submit-button') await page.waitForNavigation() await page.screenshot({ path: screenshot, fullPage: true }) console.log('See screenshot: ' + screenshot) } catch (e) { console.error(e) } finally { browser.close() } })() 3. 実行する 以下のコマンドを実行することで、./screenshot/ 以下にファイルが作成されます。 example.sh docker build -t puppeteer-chrome-linux-root . docker run -i --init --rm --cap-add=SYS_ADMIN \ --shm-size=256m \ -v "$(pwd)/screenshot:/screenshot" \ -w /screenshot/ \ --name puppeteer-chrome puppeteer-chrome-linux-root \ node -e "`cat example.js`" 備考 --no-sandbox を利用することについて Chrome(chromium) にはでホストを守るための Sandbox 機能があります。これは信頼できないサイトなどを閲覧するときにホストに影響が出ないようにするための機能です。今回はテスト環境へのアクセスを伴うテストのため、 --no-sandbox 利用でも問題ないといえます。 screenshot ディレクトリに 777 を与えることについて もっと大切なデータなどはこのような簡易的な方法ではなく、ほかの記事にあるような uid、gid をそろえる方法などを取るのがよいと思います。今回は、簡便に取得したかったため、この方法を取りました。 雑感 コンテナベースにすることで、手軽にCI で利用できるようなり、簡単なテストを定期的に実行できるようになりました。 また、AWS CloudWatch synthetics では、Puppeteer をラップしたスクリプトを実行できるようなので、そちらも試してみたいなと思いました。 参考 https://github.com/puppeteer/puppeteer/blob/main/docs/troubleshooting.md#running-puppeteer-in-docker https://chromium.googlesource.com/chromium/src/+/HEAD/docs/linux/sandboxing.md https://peter.sh/experiments/chromium-command-line-switches/#no-sandbox-and-elevated https://docs.docker.com/storage/bind-mounts/

前提 docker でrails アプリを立ち上げて、 Yay! You’re on Rails!を表示できている。 とりあえず"docker compose run web"をつける 例えば、userモデルをdocker上で作りたい場合、 docker compose run web rails g model User user_name:string{64} おまけ こんな記述の仕方だと見やすいかも。 % docker compose run web rails g model Product \ product_name:string{64} \ category_id:bigint \ price:integer \ description:string{256} \ sale_status_id:bigint \ product_status_id:bigint \ regist_date:timestamp \ user_id:bigint \ delete_flag:boolean \ + enterキーで、ターミナル上での改行ができる。 migrationファイル作るときは見やすい。 docker compose run web rails g model モデル名はタイポしないようにしよう。 間違えた名前のファイルができて面倒な事になる。 他は、適宜migrationファイルをいじれば良いのでタイポしてもそこまで影響はない。

今回はDockerを使ってJenkinsのインストールを試してみたいと思います。 jenkinsイメージの取得 まずは以下のコマンドを実行してjenkinsのイメージをダウンロードします。 docker pull jenkins/jenkins:latest docker images #中にjenkinsのイメージが存在していればOK Jenkinsの起動 Jenkinsを起動するには以下のコマンドを実行します。 起動時にport番号を指定しています。 docker run -p 8080:8080 -p 50000:50000 jenkins/jenkins:latest 上記コマンドでも起動は可能ですが、再起動のたびに設定が全て消えてしまいます。 設定を保存する場合は、事前に設定保存用のディレクトリを作成してから以下のコマンドを実行します。 mkdir <設定保存先パス>/jenkins_home chown -R 1000:1000 <設定保存先パス>/jenkins_home #これを実行しないと権限拒否のエラーが発生する docker run -p 8080:8080 -p 50000:50000 -v <設定保存先パス>/jenkins_home:/var/jenkins_home jenkins/jenkins:latest 上記コマンド実行後、以下のメッセージでフリーズしますが、http://<サーバーIP>:8080へアクセス出来れば問題ありません。 フォアグラウンドで実行しているため、ctrl + cを入力するとjenkinsのタスクを強制終了します。 バックグラウンドで起動する場合（デタッチド）、コマンドに-dオプションを追加して実行します。 INFO hudson.WebAppMain$3#run: Jenkins is fully up and running http://<サーバーIP>:8080へアクセスすると、以下のような画面が表示されます。 ここで入力するパスワードは、コマンドラインのPlease use the following password to proceed to installation:というメッセージの下の行に出力されています。 次に以下の画面が表示されます。 左のボタンは選択可能なプラグインを全てインストールし、右のボタンは必要なプラグインのみ選択してインストールするようです。 特にプラグインを選択する必要が無ければ左の「Install suggested plugins」をクリックします。 プラグイン選択後は以下のような画面に移ります。 ちなみにフォアグラウンドで起動している場合、この画面の状態でコマンドラインを確認するとインストールの処理が流れている事がわかります。 インストール完了後、管理者アカウントの作成画面が表示されます。 管理者アカウント作成または「Skip and continue as admin」押下後(？)、以下の画面が表示されますので、「Start using Jenkins」をクリックします。 すると以下のJenkinsのトップ画面が表示されます。 以上でJenkinsの起動が完了です。 今回はここまでです。 次回移行どこかでdockerfileやdocker-composeを使ったjenkinsの構築を試してみたいと思います。

概要 dockerコンテナ内でGPUが使用できず、下記のようなエラーが出た。 docker-container-runtimeのエラーのよう。 コンテナでGPUが使用できるか下記コマンドで確認を行なった。 docker run --gpus all nvidia/cuda:10.0-cudnn7-devel-ubuntu18.04 nvidia-smi 結果としては、下記のエラー Error response from daemon: could not select device driver "" with capabilities: [[gpu]]. 解決法 docker-container-runtimeのエラーは下記三つで解決を図る ①/etc/docker/daemon.jsonへの記載 ②デーモンの再起動(sudo systemctl restart docker) ③docker-container-runtimeの再インストール しかし、今回の場合は解決できない。 →dockerを再インストールすることで解決できた。 参考までに 機械学習では、dockerコンテナ内でjupyterを使ったり、スクリプトを使用したりする。 tensorflowとcudaには互換性があるので、tensorflowのバージョンによってcudaのバージョンを下げたい時等に便利だ。 docker内でGPUを使用する方法を簡単に記載する。 1. dockeを公式を参考にインストール(Qiita等を利用しても良いが、公式のやり方と照らし合わせよう) 2. nvidia-cuda-toolkitを公式からインストール（過去のも出てくる、nvidia-uninstallで削除） 3. cudaのパスを通す(/usr/local/cuda-*.←削除すれば消える) 4. nvidia-container-toolkitとnvidia-container-runtimeをインストール 5. docker-composeをインストール(※version3指定はruntimeオプションが使えない) 6. /etc/docker/daemon.jsonを編集 7. dockerの立ち上げ 8. nvidia-smiで確認(cudaはnvcc -V)

Docker、Swagger、Stoplight Prismを使用したAPI仕様書作成＋APIモックサーバーの構築方法についてメモする。 Swaggerとは REST APIのドキュメント記載に関するフォーマット仕様とswagger-uiやswagger-editorなどの周辺ツールを指す。 ツール 説明 Swagger Spec OpenAPI仕様に則ったAPI仕様 Swagger Editer OpenAPI仕様に則ったAPI仕様を書くためのエディタ Swagger UI OpenAPI仕様に則ったAPI仕様からドキュメントを生成するツール Swagger Codegen OpenAPI仕様に則ったAPI仕様からコードを生成するツール Stoplight Prism Stoplight社が提供するOSSのモックサーバー。 Swagger Specを読み込むことで、APIモックサーバーを起動する。 事前準備 docker, docker-compose のインストール。 インストール方法は割愛する。 環境構築 ディレクトリ構成 SwaggerTest --- docker-compose.yml L_ api_reference.yaml docker-compose.yml version: "3" services: swagger-editor: image: swaggerapi/swagger-editor container_name: "swagger-editor" ports: - "10081:8080" swagger-ui: image: swaggerapi/swagger-ui container_name: "swagger-ui" ports: - "10082:8080" volumes: - ./api_reference.yaml:/usr/share/nginx/html/api_reference.yaml environment: API_URL: api_reference.yaml swagger-api: image: stoplight/prism:3 container_name: "swagger-api" ports: - "10083:4010" command: mock -h 0.0.0.0 /api_reference.yaml volumes: - ./api_reference.yaml:/api_reference.yaml api_reference.yaml(Swagger Spec) Petstore APIのyamlファイル(公式)を利用する。 動作確認 コンテナ起動 SwaggerTestディレクトリに移動し、以下のコマンドを実行する。 docker-compose up Swagger Editor http://localhost:10081 にアクセスし、以下の画面が表示されることを確認する。 Swagger UI http://localhost:10082 にアクセスし、以下の画面が表示されることを確認する。 Stoplight Prism (APIモックサーバー) 以下のリクエストを行い、以下のレスポンスが返却されることを確認する。 リクエスト GET /pets HTTP/1.1 Host: localhost:10083 レスポンス(期待値) [ { "id": 0, "name": "string", "tag": "string" } ] 参考情報 Swaggerの概要をまとめてみた。 Swagger OpenAPIでAPI Referenceを書く Stoplight Prism docs

dockerで開発するときにwsl2上にあるファイルをmountしている場合、コンテナ内で作成したファイルをwsl2側で編集しようとすると「Permission denied」になります。大体の場合コンテナ内ではrootユーザーで操作され、wsl側ではroot以外のユーザーで操作されているはずなので、コンテナ内で作成されたファイルに対してはroot以外のユーザーには書き込みの権限がありません。 // wsl側で見た場合 $ ls -l test.txt -rw-r--r-- 1 root root 0 May 2 13:37 test.txt // コンテナ側から見た場合 # ls -l test.txt -rw-r--r-- 1 root root 0 May 2 04:37 test.txt コンテナ内で作成したファイルをwsl側で編集できるように毎回権限を変えるのもあれなので、この問題を解決するために、VSCodeのRemote - Containersを使います。wsl側のファイルをコンテナに取り込み、vscodeでrootユーザーで編集できるようにします。 拡張機能をインストール Remote Containersを単独でインストールしてもいいですが、Remote Developmentというエクステンションパックがおすすめです。これには、Remote - ContainersだけでなくRemote - SSHとRemote - WSLが追加で含まれておりvscodeでのリモート開発を便利にしてくれます。 セットアップ 拡張機能がインストールできたら、vscodeのスタータスバーの左下にある緑のアイテムをクリックします。 [Remote-Containers: ReOpen in Container...]を選択します。 [From a predefined container configuration definition..]を選択します。 すると、どのコンテナで起動するかを選べるのでお好みのコンテナを選択します。 コンテナを選択すると、vscodeのプロジェクト直下に.devcontainerというディレクトリがつくられ、devcontainer.jsonとDockerfileが作成されています。devcontainer.jsonにはコンテナの設定が記述されています。デフォルトだとuserがvscodeになっているので、こちらをコメントアウトするかrootに書き換えます。 devcontainer.json // For format details, see https://aka.ms/devcontainer.json. For config options, see the README at: // https://github.com/microsoft/vscode-dev-containers/tree/v0.166.1/containers/debian { "name": "Debian", "build": { "dockerfile": "Dockerfile", // Update 'VARIANT' to pick an Debian version: buster, stretch "args": { "VARIANT": "buster" } }, // Set *default* container specific settings.json values on container create. "settings": { "terminal.integrated.shell.linux": "/bin/bash" }, // Add the IDs of extensions you want installed when the container is created. "extensions": [], // Use 'forwardPorts' to make a list of ports inside the container available locally. // "forwardPorts": [], // Uncomment to use the Docker CLI from inside the container. See https://aka.ms/vscode-remote/samples/docker-from-docker. // "mounts": [ "source=/var/run/docker.sock,target=/var/run/docker.sock,type=bind" ], // Uncomment when using a ptrace-based debugger like C++, Go, and Rust // "runArgs": [ "--cap-add=SYS_PTRACE", "--security-opt", "seccomp=unconfined" ], // Comment out connect as root instead. More info: https://aka.ms/vscode-remote/containers/non-root. "remoteUser": "root" } 設定はこれだけなので、コンテナをrebuildして設定を反映させます。rebuildするにはステータスバーの左下の緑のアイテムをクリックし[Remote-Containers: Rebuild Container]を選択します。 ctrl + shift + @でターミナルを起動すると、このコンテナのシェルに接続できます。whoamiと入力するとrootユーザーで実行できていることが分かります。 これでwslのファイルをマウントさせたコンテナ内で作成したファイルに対して、vscodeで編集できるようになりました。

はじめに ポートフォリオの開発環境をDockerで構築することにしました。 なぜDockerを開発環境として選んだのかを改めて自分で理解するために、Dockerのメリットをまとめてみました。 参考文献 Docker/Kubernetes 実践コンテナ開発入門 Dockerとは何なのか？ 仮想環境の一つです。 仮想環境とは一つのハードウェアの中で、仮想的な環境を構築したもので、一つのハードウェアで複数のサーバーを仮想的に動作させることもできます。 Dokcerは仮想環境の中でもコンテナ型仮想環境という種類の仮想環境になります。 Dockerの特徴としましては、軽量で高速で動き、環境の差異に左右されにくいという特徴があります。 仮想環境には大きく種類が二つあり、ホスト型仮想環境とコンテナ型仮想環境の2種類があります。 ホスト型仮想化とコンテナ型仮想化の違い 上の図で簡単に違いを表しています。 ホストOS型はハードウェア上に仮想化ソフトウェアをインストールし、仮想化ソフトウェアで仮想マシンを稼働させます。 そのため、ミドルウェアを仮想環境ごとにインストールしなければなりません。ホストOSと仮想化ソフトウェアを動作させるので、ハードウェアにかかるリソースは大きいです。 コンテナ型はアプリケーションの実行に必要な部分だけを含み、ホストOSのカーネルを共有するので動作が早いです。 コンテナ型はホストOSの動作の一部としてコンテナが動作するイメージです。 Dockerのメリット ホスト型仮想化との違いを踏まえた上で、私が考えるDockerのメリットを紹介します。 優れた移植性 Dockerはローカル環境と本番環境をほぼ同等に再現することができます。 ローカルのDocker環境で実行しているコンテナを別のサーバーにあるローカル環境にデプロイしたり、逆のこともできます。 例えば、ホスト型環境で、Webサーバーをローカル環境に構築する場合は、本番環境と同じ、OSをセットアップして必要なものを導入していく環境構築が必要になります。 ですが、Dockerの場合はローカル環境でDockerのセットアップが済んでいれば、アプリケーションやミドルウェアがすでにセットアップされている状態の環境ができます。 Infrastructure as Code(インフラの構成管理）とImmutable Infrastructure(不変なインフラ) 「Infrastructure as Code」はコードでインフラの構成を定義する方法です。DockerはDockerfileやdocker-compose.ymlにインフラ構成のコードを記述してインフラを構成します。 コードを中心にすることで手作業にかかる時間を短縮します。 しかし、「Infrastructure as Code」の弱みとして、アプリケーションの頻繁なバージョン変更に対応するのが難しいという問題があります。 バージョンが変わるごとにコードの書き直すのは大変だからです。 そこで、大切になる考え方が、「Immutable Infrastructure」という考え方です。 これはある時点でのサーバーを保存して、複製していくという考え方です。サーバーに変更を加えたい場合は、インフラをアップデートするのではなく、作り直して、新しいサーバーのイメージとして保存し、複製します。一度セットアップしたものは２度と手を加えずに削除するので気にする必要はありません。 起動開始までの時間が短い DockerはホストOSとカーネルを共有しているため、高速で起動します。 起動が高速なため新しくインフラを作り直す「Immutable Infrastructure」と相性がいいです。 まとめ 自分のメモ用として記事を残しました。 Dockerのメリットはホスト型仮想環境を理解することで理解できることだと改めて思いました。 この記事を見て、Dockerのメリットを理解できる人がいれば幸いです。 記事で間違った情報などがありましたら、教えていただけると嬉しいです。

前提 個人的なメモのつもりで記述しています。（気が向くままに書いていきます。） 各ファイルの解説は時間があれば、少しずつ追記していく予定です。 各ファイル docker-compose.yml docker-compose.yml version: "3" services: mssql1: build: ./mssql image: localhost:6000/mssql:2019-latest container_name: mssql1 hostname: mssql1 restart: always networks: sql_backend: ipv4_address: 172.16.0.10 volumes: - mssql_volume1:/var/opt/mssql/ ports: - 11433:1433 environment: - ACCEPT_EULA=Y - SA_PASSWORD=Passw0rd - MSSQL_LCID=1041 - TZ=Asia/Tokyo - CLUSTER=PRIMARY mssql2: image: localhost:6000/mssql:2019-latest container_name: mssql2 hostname: mssql2 restart: always networks: sql_backend: ipv4_address: 172.16.0.11 volumes: - mssql_volume2:/var/opt/mssql/ ports: - 21433:1433 environment: - ACCEPT_EULA=Y - SA_PASSWORD=Passw0rd - MSSQL_LCID=1041 - TZ=Asia/Tokyo - CLUSTER=SECONDARY networks: sql_backend: driver: bridge ipam: driver: default config: - subnet: 172.16.0.0/24 volumes: mssql_volume1: driver: local mssql_volume2: driver: local Dockerfile FROM mcr.microsoft.com/mssql/server:2019-latest USER root RUN apt update \ && apt-get install -y iputils-ping net-tools \ && /opt/mssql/bin/mssql-conf set hadr.hadrenabled 1 COPY [ \ "dbm_certificate.cer", \ "dbm_certificate.pvk", \ "/var/opt/mssql/data/" \ ] WORKDIR /docker-entrypoint-initdb.d COPY ./initdb.d/ /docker-entrypoint-initdb.d/ RUN chmod -R +x /docker-entrypoint-initdb.d ENTRYPOINT ["/bin/bash", "./entrypoint.sh"] entrypoint.sh entrypoint.sh #!/bin/bash /docker-entrypoint-initdb.d/init.sh & /opt/mssql/bin/sqlservr init.sh init.sh #!/bin/bash # ファイルで初期化済みかを判断する if [ ! -f /var/opt/mssql/data/init_process.txt ]; then touch /var/opt/mssql/data/init_process.txt sleep 60 echo "##########################" echo "共通処理" echo "##########################" /opt/mssql-tools/bin/sqlcmd -S localhost -U sa -P Passw0rd -i /docker-entrypoint-initdb.d/common.sql if [ $CLUSTER = "PRIMARY" ]; then echo "##########################" echo "プライマリサーバー処理" echo "##########################" /opt/mssql-tools/bin/sqlcmd -S localhost -U sa -P Passw0rd -i /docker-entrypoint-initdb.d/primary.sql echo "-----------------------" echo " DB 作成" /opt/mssql-tools/bin/sqlcmd -S localhost -U sa -P Passw0rd -i /docker-entrypoint-initdb.d/createDatabase.sql elif [ $CLUSTER = "SECONDARY" ]; then sleep 60 echo "##########################" echo "セカンダリサーバー処理" echo "##########################" /opt/mssql-tools/bin/sqlcmd -S localhost -U sa -P Passw0rd -i /docker-entrypoint-initdb.d/secondary.sql else echo "##########################" echo "その他" echo "##########################" fi else echo "#############################" echo " 初期化済みのため、処理スキップ " echo "#############################" fi common.sql common.sql PRINT '=======================================' PRINT ' プライマリ・セカンダリ共通クエリ 実行' PRINT '=======================================' USE [master] GO PRINT '=================================' PRINT '使用最大メモリの設定' EXEC sp_configure 'show advanced options', 1; GO RECONFIGURE; GO EXEC sp_configure 'max server memory', 1024; GO RECONFIGURE; GO PRINT '=================================' PRINT 'AlwaysOn_health イベント セッションを有効化' ALTER EVENT SESSION AlwaysOn_health ON SERVER WITH (STARTUP_STATE=ON); GO PRINT '=================================' PRINT 'マスターキー作成' CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Passw0rd'; GO PRINT '=================================' PRINT '証明書を作成' CREATE CERTIFICATE dbm_certificate FROM FILE = '/var/opt/mssql/data/dbm_certificate.cer' WITH PRIVATE KEY ( FILE = '/var/opt/mssql/data/dbm_certificate.pvk', DECRYPTION BY PASSWORD = 'Passw0rd' ); GO PRINT '=================================' PRINT 'エンドポイントを作成' CREATE ENDPOINT [Hadr_endpoint] AS TCP (LISTENER_IP = (0.0.0.0), LISTENER_PORT = 5022) FOR DATA_MIRRORING ( ROLE = ALL, AUTHENTICATION = CERTIFICATE dbm_certificate, ENCRYPTION = REQUIRED ALGORITHM AES ); GO IF (SELECT state FROM sys.endpoints WHERE name = N'Hadr_endpoint') <> 0 BEGIN PRINT '●================================' ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED END GO primary.sql primary.sql PRINT '=================================' PRINT ' プライマリサーバー用処理 実行 ' PRINT '=================================' use [master] GO PRINT '-------------------------------' PRINT ' TestDB作成　&　フルバックアップ' CREATE DATABASE [TestDB]; ALTER DATABASE [TestDB] SET RECOVERY FULL; BACKUP DATABASE [TestDB] TO DISK = N'/var/opt/mssql/data/TestDB.bak'; PRINT '-------------------------------' PRINT ' AlwaysOn_health イベント セッションを有効' ALTER EVENT SESSION [AlwaysOn_health] ON SERVER STATE=START GO PRINT '-------------------------------' PRINT ' 可用性グループ作成 ' CREATE AVAILABILITY GROUP [MyAg] WITH ( AUTOMATED_BACKUP_PREFERENCE = SECONDARY, DB_FAILOVER = ON, CLUSTER_TYPE = NONE, REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 0 ) FOR DATABASE TestDB REPLICA ON N'mssql1' WITH ( ENDPOINT_URL = N'TCP://mssql1:5022', FAILOVER_MODE = MANUAL, AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, BACKUP_PRIORITY = 50, SEEDING_MODE = AUTOMATIC, SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL) ) , N'mssql2' WITH ( ENDPOINT_URL = N'TCP://mssql2:5022', FAILOVER_MODE = MANUAL, AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, BACKUP_PRIORITY = 50, SEEDING_MODE = AUTOMATIC, SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL) ) ; GO ALTER AVAILABILITY GROUP [MyAg] GRANT CREATE ANY DATABASE GO secondary.sql secondary.sql PRINT '=================================' PRINT ' セカンダリサーバー用処理 実行' PRINT '=================================' use [master] GO ALTER AVAILABILITY GROUP [MyAg] JOIN WITH (CLUSTER_TYPE = NONE); GO ALTER AVAILABILITY GROUP [MyAg] GRANT CREATE ANY DATABASE; GO createDatabase.sql createDatabase.sql PRINT '=================================' PRINT ' データベース作成.sql 実行' PRINT '=================================' PRINT '-------------------------------' PRINT ' ConfigDB作成　&　フルバックアップ' USE [master] GO CREATE DATABASE [AK_ConfigDB] GO ALTER DATABASE [AK_ConfigDB] SET RECOVERY FULL GO BACKUP DATABASE [AK_ConfigDB] TO DISK = N'/var/opt/mssql/data/AK_ConfigDB.bak'; GO PRINT '------------------------------------------' PRINT ' AVAILABILITY GROUP にDB(AK_ConfigDB)を追加' ALTER AVAILABILITY GROUP MyAg ADD DATABASE AK_ConfigDB GO

はじめに RISC-VのVector拡張(v0.10対応)のプログラム環境の構築をDockerで行ってみました．以下のもののインストールとビルドを行ったリポジトリを作成しました. riscv-gnu-toolchain riscv-isa-sim(spike) riscv-pk イメージサイズは900MB程度に収めたので，自分で一から環境構築をするよりいいと思います．通常これらのインストールとビルドを新しく仮想環境を作成してローカル環境でやると，17GB~程度使用されるのと時間もかかるので，RISC-VのVector拡張を少し試してみたいといった人には良いのではないかと思います． 注) 本記事の内容について，私も詳しくはないので色々間違っていたらすいません． 概要 RISC-VではV拡張(vector extension)の仕様が固まりつつあるようで，現在のstableなバージョンはv0.10です． またsifiveによるとllvmとgccでRISC-V Vector Intrinsicsをサポートする新しいAPIを作成したらしいです． APIのGitHubはこちらです． また，RVVの組み込み関数(intrinsics)をriscv-gnu-toolchainに統合したので，ベクタ拡張の組み込み関数対応のGNUツールチェインを構築できるみたいです．RISC-Vのベクタ拡張のプログラミング環境が整いつつあるようなので，環境構築をしてDockerで皆さんに共有できれば思いました． インストールとビルドするもの 今回の私のDockerイメージを作成するにあたってやったことを説明します．これらのインストールとビルドは既に私のDockerイメージで行われているので，利用する際は時間の節約になるのではないかと思います． riscv-gnu-toolchain (rvv-intrinsic) まずは，riscvのgccとかが入っているriscv-gnu-toolchainをインストールします．これが一番重要なものです．riscv-gnu-toolchainのブランチにはrvv-intrinsicというブランチがあり，そのブランチが先ほどsifiveのブログで言ってたものと同じものだと思うのでこのブランチをgit cloneし，ビルドをしていきます． このインストールとビルドが結構時間がかかります．たぶんローカルでやったら一時間は少なくともかかるでしょう．(たぶん) 私のdockerイメージではインストールとビルドが終わっているので楽だと思います． riscv-isa-sim (spike) riscvのシミュレータのspikeもインストールします．こちらはmasterブランチの最新のもので問題なさそうです． こちらもriscv-gnu-toolchainと同様にインストールとビルドします． riscv-pk riscv-pkは，静的にリンクされたRISC-VELFバイナリをホストできる軽量のアプリケーション実行環境です． 正直あんまり良くわかってないですが，I/Oのシステムコールが使える，というところでしょうか？これについてもインストールとビルドします． Dockerfile 上で記したものをもとに，Dockerfileを作成しました．最初に試したときは，ローカルでのimageサイズが17GB以上になってしまったので，工夫をする必要がありました． riscv関連のものは $RISCV フォルダにインストールされます．このDockerfileでは /opt/riscv にインストールされるので，Dockerのマルチステージビルドというものを使って，最初のステージで出てきた成果物である /opt/riscv フォルダだけを最終的なイメージにコピーすることで大幅にイメージサイズを縮小することができました． Dockerfile FROM ubuntu:latest RUN apt-get update && apt-get upgrade -y RUN apt-get install -y tzdata # riscv パス ENV RISCV=/opt/riscv ENV PATH=$RISCV/bin:$PATH # timezone setting ENV TZ=Asia/Tokyo RUN apt-get install -y git autoconf automake autotools-dev curl python3 libmpc-dev libmpfr-dev libgmp-dev gawk build-essential bison flex texinfo gperf libtool patchutils bc zlib1g-dev libexpat-dev # riscv-gnu-toolchainのrvv-intrinsicブランチ RUN git clone https://github.com/riscv/riscv-gnu-toolchain && \ cd riscv-gnu-toolchain && \ git checkout rvv-intrinsic && \ ./configure --prefix=/opt/riscv && \ make newlib -j$(nproc) # riscv Spike RUN apt-get install -y device-tree-compiler RUN git clone https://github.com/riscv/riscv-isa-sim.git && \ cd riscv-isa-sim && \ mkdir build && \ cd build && \ ../configure --prefix=$RISCV && \ make -j$(nproc) && \ make install # riscv procy kernel RUN git clone https://github.com/riscv/riscv-pk && \ cd riscv-pk && \ mkdir build && \ cd build && \ ../configure --prefix=$RISCV --host=riscv64-unknown-elf && \ make -j$(nproc) && \ make install # ================================================================　マルチステージビルド FROM ubuntu:latest RUN apt-get update && apt-get upgrade -y RUN apt-get install -y tzdata # 実行に最低限必要そうなパッケージ RUN apt-get install -y gcc device-tree-compiler # timezone setting ENV TZ=Asia/Tokyo # set local to jp RUN apt-get install -y language-pack-ja && \ update-locale LANG=ja_JP.UTF-8 ENV LANG ja_JP.UTF-8 ENV LANGUAGE ja_JP:ja ENV LC_ALL ja_JP.UTF-8 # riscv パス ENV RISCV=/opt/riscv ENV PATH=$RISCV/bin:$PATH # homeディレクトリへ WORKDIR /home # デフォルトのdash から bashへ sourceコマンドが使えないから SHELL ["/bin/bash", "-c"] CMD ["/bin/bash"] COPY --from=0 /opt/riscv/ /opt/riscv サイズの比較 こちらが最終的なイメージサイズになります．912.23MBとなりました． 調べると，@kamiya_owlさんがriscv-gnu-toolchain(V拡張ではない)のdockerのイメージを公開していらっしゃるようでした．下が@kamiya_owl氏のサイトです．docker imageのサイズを確認してみたところ4.34 GBありました． UCB(University of California, Berkeley：カリフォルニア大学バークレー校)が公開している ChipyardリポジトリのDocker image( https://hub.docker.com/r/ucbbar/chipyard-image/tags?page=1&ordering=last_updated )は1.68GBでした．こちらは色々でかいリポジトリなので比較対象には微妙ですが参考にはなるかと思います． 以上のものと比較しても，まあまあサイズを抑えられたかなと思います．ただ@kamiya_owlさんのものと違ってビルドの成果物だけをデプロイ(?)しているので，「自分でカスタム命令を実装する!」という用途にはあまり向いていないので，「ちょっとベクタ拡張を試してみたい」といった人には良いかなと思います． おわりに Dockerについて分からないところも多かったですが，やってみました． DockerとGithubを連携させた，automated buildというものもやってみたのですが，docker hubでの自動ビルドにはメモリの制限が厳しいようで，エラーになって出来ませんでした．成功した方などは教えていただければ嬉しいです． 本記事については無駄なところや，間違ったところもあると思うので何かありましたら @a163236 まで教えて頂けると幸いです。

はじめに RISC-VのVector拡張(v0.10対応)のプログラム環境の構築をDockerで行ってみました．以下のもののインストールとビルドを行ったリポジトリを作成しました. riscv-gnu-toolchain riscv-isa-sim(spike) riscv-pk イメージサイズは900MB程度に収めたので，自分で一から環境構築をするよりいいと思います．通常これらのインストールとビルドを新しく仮想環境を作成してローカル環境でやると，17GB~程度使用されるのと時間もかかるので，RISC-VのVector拡張を少し試してみたいといった人には良いのではないかと思います． 注) 本記事の内容について，私も詳しくはないので色々間違っていたらすいません． 概要 RISC-VではV拡張(vector extension)の仕様が固まりつつあるようで，現在のstableなバージョンはv0.10です． またsifiveによるとllvmとgccでRISC-V Vector Intrinsicsをサポートする新しいAPIを作成したらしいです． APIのGitHubはこちらです． また，RVVの組み込み関数(intrinsics)をriscv-gnu-toolchainに統合したので，ベクタ拡張の組み込み関数対応のGNUツールチェインを構築できるみたいです．RISC-Vのベクタ拡張のプログラミング環境が整いつつあるようなので，環境構築をしてDockerで皆さんに共有できれば思いました． インストールとビルドするもの 今回の私のDockerイメージを作成するにあたってやったことを説明します．これらのインストールとビルドは既に私のDockerイメージで行われているので，利用する際は時間の節約になるのではないかと思います． riscv-gnu-toolchain (rvv-intrinsic) まずは，riscvのgccとかが入っているriscv-gnu-toolchainをインストールします．これが一番重要なものです．riscv-gnu-toolchainのブランチにはrvv-intrinsicというブランチがあり，そのブランチが先ほどsifiveのブログで言ってたものと同じものだと思うのでこのブランチをgit cloneし，ビルドをしていきます． このインストールとビルドが結構時間がかかります．たぶんローカルでやったら一時間は少なくともかかるでしょう．(たぶん) 私のdockerイメージではインストールとビルドが終わっているので楽だと思います． riscv-isa-sim (spike) riscvのシミュレータのspikeもインストールします．こちらはmasterブランチの最新のもので問題なさそうです． こちらもriscv-gnu-toolchainと同様にインストールとビルドします． riscv-pk riscv-pkは，静的にリンクされたRISC-VELFバイナリをホストできる軽量のアプリケーション実行環境です． 正直あんまり良くわかってないですが，I/Oのシステムコールが使える，というところでしょうか？これについてもインストールとビルドします． Dockerfile 上で記したものをもとに，Dockerfileを作成しました．最初に試したときは，ローカルでのimageサイズが17GB以上になってしまったので，工夫をする必要がありました． riscv関連のものは $RISCV フォルダにインストールされます．このDockerfileでは /opt/riscv にインストールされるので，Dockerのマルチステージビルドというものを使って，最初のステージで出てきた成果物である /opt/riscv フォルダだけを最終的なイメージにコピーすることで大幅にイメージサイズを縮小することができました． Dockerfile FROM ubuntu:latest RUN apt-get update && apt-get upgrade -y RUN apt-get install -y tzdata # riscv パス ENV RISCV=/opt/riscv ENV PATH=$RISCV/bin:$PATH # timezone setting ENV TZ=Asia/Tokyo RUN apt-get install -y git autoconf automake autotools-dev curl python3 libmpc-dev libmpfr-dev libgmp-dev gawk build-essential bison flex texinfo gperf libtool patchutils bc zlib1g-dev libexpat-dev # riscv-gnu-toolchainのrvv-intrinsicブランチ RUN git clone https://github.com/riscv/riscv-gnu-toolchain && \ cd riscv-gnu-toolchain && \ git checkout rvv-intrinsic && \ ./configure --prefix=/opt/riscv && \ make newlib -j$(nproc) # riscv Spike RUN apt-get install -y device-tree-compiler RUN git clone https://github.com/riscv/riscv-isa-sim.git && \ cd riscv-isa-sim && \ mkdir build && \ cd build && \ ../configure --prefix=$RISCV && \ make -j$(nproc) && \ make install # riscv procy kernel RUN git clone https://github.com/riscv/riscv-pk && \ cd riscv-pk && \ mkdir build && \ cd build && \ ../configure --prefix=$RISCV --host=riscv64-unknown-elf && \ make -j$(nproc) && \ make install # ================================================================　マルチステージビルド FROM ubuntu:latest RUN apt-get update && apt-get upgrade -y RUN apt-get install -y tzdata # 実行に最低限必要そうなパッケージ RUN apt-get install -y gcc device-tree-compiler # timezone setting ENV TZ=Asia/Tokyo # set local to jp RUN apt-get install -y language-pack-ja && \ update-locale LANG=ja_JP.UTF-8 ENV LANG ja_JP.UTF-8 ENV LANGUAGE ja_JP:ja ENV LC_ALL ja_JP.UTF-8 # riscv パス ENV RISCV=/opt/riscv ENV PATH=$RISCV/bin:$PATH # homeディレクトリへ WORKDIR /home # デフォルトのdash から bashへ sourceコマンドが使えないから SHELL ["/bin/bash", "-c"] CMD ["/bin/bash"] COPY --from=0 /opt/riscv/ /opt/riscv サイズの比較 こちらが最終的なイメージサイズになります．912.23MBとなりました． 調べると，@kamiya_owlさんがriscv-gnu-toolchain(V拡張ではない)のdockerのイメージを公開していらっしゃるようでした．下が@kamiya_owl氏のサイトです．docker imageのサイズを確認してみたところ4.34 GBありました． UCB(University of California, Berkeley：カリフォルニア大学バークレー校)が公開している ChipyardリポジトリのDocker image( https://hub.docker.com/r/ucbbar/chipyard-image/tags?page=1&ordering=last_updated )は1.68GBでした．こちらは色々でかいリポジトリなので比較対象には微妙ですが参考にはなるかと思います． 以上のものと比較しても，まあまあサイズを抑えられたかなと思います．ただ@kamiya_owlさんのものと違ってビルドの成果物だけをデプロイ(?)しているので，「自分でカスタム命令を実装する!」という用途にはあまり向いていないので，「ちょっとベクタ拡張を試してみたい」といった人には良いかなと思います． おわりに Dockerについて分からないところも多かったですが，やってみました． DockerとGithubを連携させた，automated buildというものもやってみたのですが，docker hubでの自動ビルドにはメモリの制限が厳しいようで，エラーになって出来ませんでした．成功した方などは教えていただければ嬉しいです． 本記事については無駄なところや，間違ったところもあると思うので何かありましたら @a163236 まで教えて頂けると幸いです。

概要 docker-postfixを使用してDockerのコンテナ内リンク（またはローカルネットワークやVPN）からの送信専用SMTPリレー（SMTPサーバ）を構築した際のメモ。 作者公式Dockerイメージをdocker-composeでハンドリングしてDKIMに対応させる。自身の用途としてはdocker-composeで構築したオンプレアプリ類からユーザーへのメール配信用。 なお、実績のないドメインからのメールはSPFもDKIMも関係なく問答無用で迷惑メール扱いされるのが普通で、アカウント云々の文言が含まれる場合は尚更である。ユーザーへの念押しは必須。 ※RHEL8互換環境を想定、それ以外の場合は必要に応じて読み替えのこと 準備 DKIM docker-postfixではDKIMはoptionalのため、鍵は自分で用意する必要がある。今回はホスト上で作成してvolumesでマウントする。 パッケージのインストール DKIM鍵を生成するためにホストにOpenDKIMと依存パッケージをインストールする。 shell dnf install -y opendkim perl-Getopt-Long OpenDKIMはEPELに収録されている 鍵の生成 shell mkdir -p /etc/opendkim/keys/<DOMAIN> opendkim-genkey -b 2048 -d <DOMAIN> -D /etc/opendkim/keys/<DOMAIN> -s <SELECTOR> -v <DOMAIN> は使用するドメイン名（ exmaple.com 等） <SELECTOR> はDKIM鍵の識別名のようなもの（例えば mail 等） 指定しないと default になる 実行すると秘密鍵が /etc/opendkim/keys/<DOMAIN>/<SELECTOR>.private に生成され、TXTレコードの内容が /etc/opendkim/keys/<DOMAIN>/<SELECTOR>.txt に出力される DNS DKIMレコード 出力された /etc/opendkim/keys/<DOMAIN>/<SELECTOR>.txt を元にDNSにDKIMレコードを追加する。OpenDKIMが出力するテキストはzoneファイルの書式のためbindならそのまま使える。 <SELECTOR>._domainkey IN TXT "v=DKIM1; k=rsa; p=MIIB......" Type: TXT Name: <SELECTOR>._domainkey Value: v=DKIM1; k=rsa; p=MIIB...... /etc/opendkim/keys/<DOMAIN>/<SELECTOR>.txt の二重引用符の中身を連結したもの TTL: 適当 LuaDNSにおける設定例 SPFレコード わかりやすい解説が大量にあるため検索して参照のこと。 <DOMAIN>. IN TXT "v=spf1 +ip4:<GLOBAL_IP>/32 -all" 修飾子 + - ~ ? はその条件に一致した場合の扱いを規定する + : 認証する（省略可）/ - : 認証しない/ ~ : 認証しないが受信推奨/ ? : 認証の有無を評価しない よって設定した条件以外で送る可能性が全くない場合、allディレクティブの修飾子は ~ ではなく厳格な - の方がより安全 LuaDNSにおける設定例 Composeファイル environmentの項目はdocker-postfixのreadmeを参照のこと。 コンテナ間リンク用設定例 docker-compose.yml version: '3.8' services: smtp: image: panubo/postfix:latest container_name: smtp hostname: smtp-server environment: - MAILNAME=<DOMAIN> - TZ=Asia/Toyo - USE_TLS=no - USE_DKIM=yes - DKIM_KEYFILE=/etc/opendkim/keys/<DOMAIN>/<SELECTOR>.private - DKIM_SELECTOR=<SELECTOR> expose: #- '25' - '587' volumes: - /etc/opendkim:/etc/opendkim networks: - container-link logging: options: max-size: "10m" max-file: "3" networks: default: external: name: bridge container-link: name: docker.internal 各コンテナで指定するSMTPサーバのアドレスはdocker-postfixコンテナのhostnameと待ち受けポートになる この設定例では smtp-server:587 を指定することになる 許可するIP範囲は明示的に指定しないと 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 に設定される コンテナ間リンクで使用する場合はそのままでOKと思われる TLSは標準でON（ USE_TLS=yes ）のため、不要なら明示的に切る必要がある コンテナ間リンク内で閉じているなら不要と思われる DKIMを有効化し、先の手順で作成したDKIM鍵をマウントして使用する コンテナ間リンクに明示的に命名したbridgeネットワークを使用している 立てたSMTPサーバを使用するコンテナはこのネットワークに繋げること 当然ながらメールにはSMTPのチェーンの始点となる送信元コンテナのhostnameとIPが記載される 内部アクセス専用のため認証はない その他設定例 ローカルIP 10.0.0.1 のアダプタ上でIPアドレス範囲 10.0.0.0/24 からのアクセスのみ待ち受ける docker-compose.yml environment: - MYNETWORKS=10.0.0.0/24 ports: - '10.0.0.1:587:587' TLSの使用を強制し、Let's Encryptの証明書と鍵を使用（使用するドメインで繋がるようにしておく必要がある） docker-compose.yml environment: - USE_TLS=yes - TLS_SECURITY_LEVEL=encrypt - TLS_KEY=/etc/letsencrypt/live/<DOMAIN>/privkey.pem - TLS_CRT=/etc/letsencrypt/live/<DOMAIN>/fullchain.pem volumes: - /etc/letsencrypt:/etc/letsencrypt 実際のヘッダー Gmailに送ったもの。 s=mail は <SELECTOR> のこと Received に送信元コンテナのホスト名とIPが入っている

シンプルにDockerを試してみる〜Ubuntuを起動してみる〜 Dockerと聞くと、なんだか難しそうなイメージを持たれがちだと思います。以前の私もそうで、手を出しづらいイメージを持っていました。 初めてDockerを試すときに、こんな感じでとにかくシンプルにまとめてあるドキュメントがあったらよかったのにと思ったのでそのメモ。 Dockerとは Dockerは、インフラ関係やDevOps界隈で注目されている技術の一つで、Docker社が開発している、コンテナ型の仮想環境を作成、配布、実行するためのプラットフォームです1。 Dockerを用いることによって何が嬉しいのか コード化された設定ファイルDockerfileを共有することで、どこでも誰でも同じ環境が作れることや、スクラップ&ビルドが容易にできることから開発に関して理想的な環境を手に入れることができる。 環境 macOS BigSur 11.2.3（20D91） Docker Desktop for Mac 20.10.5, build 55c4c88 Dockerのインストール Docker for Macをインストール 公式サイトからDockerのアカウントを作ってログイン DockerHubからダウンロードしてインストール インストール後CLIで確認してみる。 $ docker -v Docker version 20.10.5, build 55c4c88 このようにバージョンが表示されたら完了。 試しにubuntuを使ってみる まず、testフォルダーを作ってDockerfileを作成する。 $ mkdir test $ cd test $ echo "From ubuntu" > Dockerfile 次にビルドして、shellに入ってみます。 $ docker build -t test . $ docker run -it test bash $ cat /etc/os-release オプションの意味 -t タグ -i インタラクティブ(アタッチしていなくても STDIN を開き続ける) 無事にUbuntuが起動できればこのようなメッセージが表示されると思います。 NAME="Ubuntu" VERSION="20.04.2 LTS (Focal Fossa)" そうなんです、これだけでUbuntuが使えてしまうのは感動しませんか。 これでDockerの動作を確認できました。 このコンテナは不要になると思うので一旦キャッシュを含めて削除しましょう。 $ docker system prune -a 以上で完了です。 「Docker入門（第一回）～Dockerとは何か、何が良いのか～」 https://knowledge.sakura.ad.jp/13265/  ↩

railsでruby:X.X.X-alpineってdocker image使っててYou must have ImageMagick or GraphicsMagick installedってエラーに遭遇した時は、次のコマンドで解決 $ docker exec {container name} apk add imagemagick apkってのがalpine linuxのpackage managerなんだけど知らなくて時間食った。yumが使えなくてずっと泣いてた