この記事の目的 Vue3 の開発環境を 30分以内に構築する！ 対象者 とりあえず Vue3 が動く環境が欲しい 素の Vue で開発したい（Nuxt.js などのフレームワークを使用しない） TypeScript で開発したい 条件 Docker, node は既に入っている それでは早速いきましょう? Step1. ローカルで適当にプロジェクト用のフォルダ掘る % mkdir vue-otameshi 名前は適当で OK です。とりあえず vue-otameshi （vue お試し）で。 Step2. docker-compose.yml 書く vue-otameshi % touch docker-compose.yml docker-compose.yml version: "3" services: setup: image: node:latest volumes: - .:/srv:cached - ~/.ssh/:/root/.ssh:ro - ~/.gitconfig:/root/.gitconfig working_dir: /srv command: yarn install app: image: node:latest ports: - 8080:8080 volumes: - .:/srv:cached working_dir: /srv command: yarn serve Step3. @vue/cli を install する vue-otameshi % docker-compose run --rm setup yarn add @vue/cli めちゃくちゃ時間かかりますが、少しの辛抱です。。 次のように出ていたら成功してます。 ├─ xtend@4.0.2 ├─ y18n@5.0.8 ├─ yallist@4.0.0 ├─ yaml-front-matter@3.4.1 ├─ yargs-parser@20.2.9 ├─ yargs@16.2.0 ├─ yauzl@2.10.0 ├─ zen-observable-ts@0.8.21 └─ zen-observable@0.8.15 Done in 691.11s. 691秒は長すぎる? Step4. vue プロジェクトを作成する vue-otameshi % docker-compose run --rm app ./node_modules/.bin/vue create . 諸々設定入ります〜 よくわからない方はとりあえず真似すれば問題なしです！ Vue CLI v4.5.13 ? Generate project in current directory? Yes Vue CLI v4.5.13 ? Please pick a preset: Manually select features ? Check the features needed for your project: Choose Vue version, Babel, TS, Router, CSS Pre-processors, Linter ? Choose a version of Vue.js that you want to start the project with 3.x ? Use class-style component syntax? No ? Use Babel alongside TypeScript (required for modern mode, auto-detected polyfills, transpiling JSX)? Yes ? Use history mode for router? (Requires proper server setup for index fallback in production) Yes ? Pick a CSS pre-processor (PostCSS, Autoprefixer and CSS Modules are supported by default): Sass/SCSS (with dart- sass) ? Pick a linter / formatter config: Standard ? Pick additional lint features: Lint on save ? Where do you prefer placing config for Babel, ESLint, etc.? In dedicated config files ? Save this as a preset for future projects? No ? Pick the package manager to use when installing dependencies: Yarn Vue CLI v4.5.13 ✨ Creating project in /srv. ? Initializing git repository... ⚙️ Installing CLI plugins. This might take a while... 成功したみたいです。 success Saved lockfile. Done in 314.19s. ⚓ Running completion hooks... ? Generating README.md... ? Successfully created project srv. ? Get started with the following commands: $ yarn serve WARN Skipped git commit due to missing username and email in git config, or failed to sign commit. You will need to perform the initial commit yourself. Step5. docker でサーバーを起動する vue-otameshi % docker-compose up app Starting vue-with-tailwind-css-practice_app_1 ... done Attaching to vue-with-tailwind-css-practice_app_1 app_1 | yarn run v1.22.4 app_1 | $ vue-cli-service serve app_1 | INFO Starting development server... . . . app_1 | DONE Compiled successfully in 22128ms1:49:35 PM app_1 | app_1 | <s> [webpack.Progress] 100% app_1 | app_1 | app_1 | App running at: app_1 | - Local: http://localhost:8080/ app_1 | app_1 | It seems you are running Vue CLI inside a container. app_1 | Access the dev server via http://localhost:<your container's external mapped port>/ app_1 | app_1 | Note that the development build is not optimized. app_1 | To create a production build, run yarn build. app_1 | app_1 | No issues found. 起動完了✨ localhost:8080 に例の画面が出てきたら OK です。 お疲れ様です。 見ていただきありがとうございました?‍♂️

概要 この記事では、M1 macでも使えるLaTeX Dockerイメージを紹介します。 Ghostscriptも含んでいますが、圧縮サイズで520MB程度です。 マルチアーキテクチャビルドしていますので、amd64な人もarm64な人も使えます。 拙稿「pman0214 - DockerでGhostscript対応LaTeX環境構築」で解説しているLaTeX on Dockerイメージが更新されています。 はじめに M1なmacになり、LaTeX on Dockerが使えなくなってしまいました。 MacTeXはサイズが大きく、ダウンロードに膨大な時間がかかります（ミラーサーバの運用者さまにおかれましては、多大なる苦労をしていることと推察いたします。ありがとうございます）。 サイズを小さくしようとするとinstall-tlを使用してインストールするなどが必要です。しかし、インストール時期によりバージョンにバラツキが生じます。複数マシンにインストールすると環境の差が生まれる場合もあります。 そこで、マルチアーキテクチャビルドでLaTeXのDockerイメージを作ることにしました。 使い方 「はじめに」に大層なことを書きましたが、使う上で解説することは実はほぼありません。 以下の拙稿をご参照ください。イメージを更新しただけですので、使い方は変わりません。 pman0214/DockerでGhostscript対応LaTeX環境構築 - Qiita pman0214/Docker+VS CodeでLaTeX環境構築 (latexmkrc依存版) - Qiita amd64なマシンからdocker pullすればamd64なイメージが、arm64なマシンからdocker pullすればarm64なイメージが取得されます。 ビルドしたい人向け ビルドに用いたファイルはGitHubで公開しています。 Dockerfileでは主に以下のことをしています。 alpineイメージをベースとし、glibcをインストール amd64, arm64で共通で使えるパッケージが無いので、ビルドしたバイナリをインストールしつつ設定 ghostscriptをインストール texをインストール ビルド環境 当方のビルド環境は以下の通りです。 Ubuntu 18.04.5 LTS Docker Docker version 20.10.7, build f0df350 Intel Core i9-9900K @3.60GHz / 64GB RAM DockerのAutomated Buildが課金されてしまうそうなので、現在は手動でビルドしています。そのうちGitHub Action化されるかもしれません。 事前準備 拙稿の「M1 macな人たちに贈るpytorch+jupyterlab docker image / 準備（linuxでビルドする場合のみ） - Qiita」を参照するなどして、マルチアーキテクチャビルド環境を準備しておきます。 ビルド アーキテクチャを指定して、buildxコマンドを使ってビルドします。 と言っても、指定できる（ビルドに成功する）アーキテクチャはlinux/amd64とlinux/arm64のみです。 % git clone https://github.com/pman0214/docker-alpine-texlive-ja-epspdf.git % cd docker-alpine-texlive-ja-epspdf % docker buildx build \ --platform linux/amd64,linux/arm64 \ -t "alpine-texlive-ja-epspdf:2021" \ . --load docker hubには以下でpushしています。 % git clone https://github.com/pman0214/docker-alpine-texlive-ja-epspdf.git % cd docker-alpine-texlive-ja-epspdf % docker buildx build \ --platform linux/amd64,linux/arm64 \ -t "pman0214/alpine-texlive-ja-epspdf:2021" \ . --push タグ付け このままではlatestタグがないイメージとなってしまうため、latestタグを付けます。 マルチアーキテクチャビルドの場合、同じ名前（タグ）で複数のイメージが存在するため、manifestを操作してタグを操作する必要があります。 作成したいタグのmanifestをmanifestに含めるイメージを指定して作成します。 % docker manifest create pman0214/alpine-texlive-ja-epspdf:latest \ pman0214/alpine-texlive-ja-epspdf@sha256:ee9ccaefff9468fae0a34af33355e880933fa56bfaab5865000081f583756621 \ pman0214/alpine-texlive-ja-epspdf@sha256:414e9dfef683e06ec91547c870c6eaec54c0d7ba484afb6ccda87a90d0656f46 sha265部分は、docker hubで確認するか、以下のようなコマンドを実行してmanifestを取得して確認します。 % docker manifest inspect pman0214/alpine-texlive-ja-epspdf:2021 この出力として、以下のようなJSONが得られます。 { "schemaVersion": 2, "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json", "manifests": [ { "mediaType": "application/vnd.docker.distribution.manifest.v2+json", "size": 1154, "digest": "sha256:7be1959252e4b31939683b99438c78343c7bbd8334485e6698d8513be2e558ed", "platform": { "architecture": "amd64", "os": "linux" } }, { "mediaType": "application/vnd.docker.distribution.manifest.v2+json", "size": 1154, "digest": "sha256:f8538f475c72014d9ac4aae5ee59e46bae657d3ce40f2f35184740f698a3ae8c", "platform": { "architecture": "arm64", "os": "linux" } } ] } 作成したmanifestをpushすれば完了です。 % docker manifest push pman0214/alpine-texlive-ja-epspdf:latest おわりに 本記事では、IntelなmacでもM1なmacでも動くlatex dockerイメージを紹介しました。 使い方は過去記事と変わらないため、使い方の説明は過去記事を参照するだけの形となっています。 一方で、ビルドについては簡単に説明しました。 特に、manifestの操作によるタグの付け方を説明しました。 これでやってM1 macでもlatexを使う気になれそうです。

Rails6 Bootstrap 導入 (docker) いくつかの記事を渡り歩かなきゃいけなくて時間かかったのでまとめておく Rails 6.1.4 ruby 2.6.8p205 (2021-07-07 revision 67951) [x86_64-linux] Docker version 20.10.5, build 55c4c88 ① app/javascript/src/application.scss 作成 app/javascript/src/application.scss @import '~bootstrap/scss/bootstrap'; //追加 ② app/javascript/packs/application.js // This file is automatically compiled by Webpack, along with any other files // present in this directory. You're encouraged to place your actual application logic in // a relevant structure within app/javascript and only use these pack files to reference // that code so it'll be compiled. import Rails from "@rails/ujs" import Turbolinks from "turbolinks" import * as ActiveStorage from "@rails/activestorage" import "channels" //追加（ここから）--------------------- import "jquery" import "bootstrap" import "../src/application" //追加(ここまで)--------------------- Rails.start() Turbolinks.start() ActiveStorage.start() ③ config/webpack/environment.js const { environment } = require('@rails/webpacker') //追加（ここから）--------------------- const webpack = require('webpack') environment.plugins.prepend('Provide', new webpack.ProvidePlugin({ $: 'jquery/src/jquery', jQuery: 'jquery/src/jquery' }) ) //追加(ここまで)--------------------- module.exports = environment ファイルの作成と修正は　これで完了 docker-compose run --rm web bash　実行 yarn add jquery bootstrap popper.js @popperjs/core 実行 これでdockerコンテナ再起動すればいける

概要 dockerを使ってPHP-Slimを動かしてみたメモ。 ついでに、starserverにftpでアップロードしたメモも残す。 なお、startserverの無料枠はhttps化できなかったので微妙だなぁと。 この時点のソース 環境 Windows10 Virtualbox 6.1.24 Vagrant 2.2.17 box - ubuntu/focal64 docker-compose 1.29.2 docker 19.03.13 git 2.32.0 環境構築 dockerの準備 laradockから必要そうなもののみ抽出して使用。 workspace php-fpm nginx mysql docker-in-docker docker/docker-compose.yml docker/.env composerでインストール docker-compose upでlaradockを立ち上げたのちに、 docker-compose exec workspace bashでworkspaceに入る。 あとは、その中でcomposer installコマンドを実行。 ファイルのアップロード curlコマンドでアップロードするshellを組んでいる。 /bin/ftp-upload_all.sh #!/bin/bash # このシェルスクリプトのディレクトリの絶対パスを取得。 bin_dir=$(cd $(dirname $0) && pwd) parent_dir=$(cd $bin_dir/.. && pwd) public_dir=$(cd $parent_dir/public && pwd) host=xxx.starfree.jp user=xxx.starfree.jp pass=xxxxx cd $public_dir curl --upload-file composer.phar --user $user:$pass ftp://$host/ curl --upload-file .htaccess --user $user:$pass ftp://$host/ curl --upload-file index.php --user $user:$pass ftp://$host/ find templates -type f -exec curl -u $user:$pass --ftp-create-dirs -T {} ftp://$host/{} \; find vendor -type f -exec curl -u $user:$pass --ftp-create-dirs -T {} ftp://$host/{} \; 参考

開発環境を豊かにする開発事例 https://qiita.com/official-events/89fd4ad3c24d7882117d に参加する記事です。 <この項は書きかけです。順次追記します。> 過去 通信エミュレータの移植 大学のセンタ計算機と研究室の端末PCとを繋ぐ通信エミュレータの移植をしました。 通信エミュレータの移植 https://qiita.com/kaizen_nagoya/items/ce505bbea4229b83e93b VZエディタの移植 DOS用のプログラマ向けエディタVZエディタを、N5200というオフィスコンピュータ用のMS-DOSに移植しました。 VZエディタ移植に当たって実施したことと成果。仮説・検証(115) https://qiita.com/kaizen_nagoya/items/5551be98dcbed8f41949 現在 docker dockerで基本なんでもやろうとしています。 gcc/clang, python/R, 文字列処理など あなたもdocker, 私もdocker https://qiita.com/kaizen_nagoya/items/8f2746f10f30b575d0a8 docker(13)設計はgit, dockerで https://qiita.com/kaizen_nagoya/items/5e85a825709f7f5f56ee docker(59) Githubとdocker https://qiita.com/kaizen_nagoya/items/f7e142cd283a1c314234 github プログラミングから文書化まで。すべてgithubでやろうとしています。 公開算譜は機敏だ(An Open Source Project is Agile)GitHub with Docker。Youtube(2) 仮説・検証（51） https://qiita.com/kaizen_nagoya/items/5dd49a046b5991af3a5e 卒業論文、修士論文、博士論文は　github/gitlab/bitbacketのprivate利用をお勧め https://qiita.com/kaizen_nagoya/items/eb9945a2649f6f3eabd0 bitbucket/github/gitlab連携環境構築　悪戦苦闘 https://qiita.com/kaizen_nagoya/items/87352fe88ceed2c1732d Github archive programって何ですか？ https://qiita.com/kaizen_nagoya/items/27cb1a6e3529a71b18a9 未来 量子計算機 量子コンピュータプログラムへの道 https://qiita.com/kaizen_nagoya/items/37c90488c87bbe9f2d71 特異点 特異点(singular point)は特異(singularity)である。仮説・検証（27) https://qiita.com/kaizen_nagoya/items/26f2ff3f24496b8252c7 ＜この記事は個人の過去の経験に基づく個人の感想です。現在所属する組織、業務とは関係がありません。＞ Qiitaエンジニアフェスタ2021 Qiitaエンジニアフェスタ2021 LGTMランキング！ https://qiita.com/torifukukaiou/items/949ff6d59ffeeec0cd51 で、goodsと、登録日、更新日の一覧を出してくださっている。 自己参加記事として viewsの一覧を作成した。 分類 表題 views goods stock Docker上のみでシステムを作るときの構成 あなたもdocker, 私もdocker https://qiita.com/kaizen_nagoya/items/8f2746f10f30b575d0a8 831 3 5 今まで買ってよかった技術書を紹介しよう！ 今まで書いてよかった技術書を紹介しよう！ https://qiita.com/kaizen_nagoya/items/d31b7c158541d345a7ef 608 3 2 開発環境を豊かにする開発事例 開発環境を豊かにする開発事例　過去・現在・未来 https://qiita.com/kaizen_nagoya/items/d9bf0c2c671fe7f1c749 183 1 0 MS開発ツール　Azure Microsoftとの歴史　Cコンパイラを中心に https://qiita.com/kaizen_nagoya/items/d7c0cc257e99de0573cf 138 1 0 文書履歴(document history) ver. 0.01 初稿 20210724 ver. 0.02 views一覧追記 20210725

はじめに 最近は会社にあるDockerホストのLinuxマシンに自宅からリモートでアクセスしている。 このような環境では、気軽にLinuxマシンのネットワーク設定を変更することができない。 ネットワークの設定でミスをすると、リモートで接続できなくなる恐れがあるためである。 このような状況で、Dockerコンテナにホストと同じLAN内のIPアドレスを割り振ることが必要になった。 検索したところ、以下の方法が見つかった。 ブリッジを作成 ホストのネットワークインターフェースを割り当てたブリッジを作成し、そのブリッジにコンテナを接続する。 この方法はリモートでアクセス不可となるタイミングがあるので今回は使用不可である。 参照： https://docs.docker.com/network/network-tutorial-standalone/ https://pj-doaa.hatenablog.com/entry/2019/09/04/144520 macvlanネットワークを作成 macvlanドライバでホストと同じLANのDockerネットワークを作成し、そのネットワークにコンテナを接続する。 この方法であれば、ホストの既存のネットワーク設定を変更する必要がないので今回は適切である。 ただし、設定手順に記載した追加のネットワーク設定を行わないと、ホストからコンテナにアクセスできない。 参照： https://docs.docker.com/network/network-tutorial-macvlan/ https://qiita.com/Meganezaru@github/items/69f406844532d731d370 https://qiita.com/okhrn/items/d8580e66546d166f489a https://base64.work/so/docker/1535501 設定手順 以下を前提とした手順を記載する。 項目 内容 ホストの名前 hostpc ホストのOS Ubuntu 16.04 ホストの物理N/W IF enp3s0 ホストのIPアドレス 172.12.224.10 ホストのLAN 172.12.224.0/20 ゲートウェイ 172.12.224.1 ホストに追加するN/W IF htoc0 追加N/W IFのIPアドレス 172.12.224.100 コンテナ1の名前 conte1 コンテナ1のIPアドレス 172.12.224.101 コンテナ2の名前 conte2 コンテナ2のIPアドレス 172.12.224.102 LAN内別PCの名前 otherpc LAN内別PCのIPアドレス 172.12.224.30 以下の手順でmacvlanネットワークとコンテナを追加する。 # docker network create -d macvlan --subnet=172.12.224.0/20 --gateway=172.12.224.1 -o parent=enp3s0 corplan # docker network ls NETWORK ID NAME DRIVER SCOPE 47187139f09e corplan macvlan local 851186fc68a8 bridge bridge local 7873fd88b23e host host local c4a08749ed89 none null local # docker run -d -it --network corplan --ip 172.12.224.101 --name conte1 ubuntu:18.04 /bin/bash # docker run -d -it --network corplan --ip 172.12.224.102 --name conte2 ubuntu:18.04 /bin/bash この時点では、pingの疎通状況が以下のようになる（ホストとコンテナ間は疎通不可）。 送信側＼受信側 hostpc conte1 conte2 otherpc hostpc - × × ○ conte1 × - ○ ○ conte2 × ○ - ○ otherpc ○ ○ ○ - コンテナ（Ubuntu 18.04）でpingを使用するためには、inetutils-pingをインストールする必要がある。 以下の手順で、ホストの物理N/W IFに結合するブリッジモードのmacvlan仮想N/W IFを追加し、追加したN/W IFのルートを設定する。 # ip link add htoc0 link enp3s0 type macvlan mode bridge # ip addr add 172.12.224.100/32 dev htoc0 # ip link set htoc0 up # ip route add 172.12.224.0/20 dev htoc0 # route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default 172.12.224.1 0.0.0.0 UG 100 0 0 enp3s0 link-local * 255.255.0.0 U 1000 0 0 enp3s0 172.17.0.0 * 255.255.0.0 U 0 0 0 docker0 172.12.224.0 * 255.255.224.0 U 0 0 0 htoc0 172.12.224.0 * 255.255.224.0 U 100 0 0 enp3s0 上記ように172.12.224.0/20のルートが2つある状態になるので、htoc0のメトリックにはenp3s0より小さい値を指定する必要がある（enp3s0のルートを削除してスッキリしたいと思うかも知れないが、カーネルが追加したルートは触らない方が安全である）。 この時点では、pingの疎通状況が以下のようになる（ホストとコンテナ間も疎通可能）。 送信側＼受信側 hostpc conte1 conte2 otherpc hostpc - ○ ○ ○ conte1 ○ - ○ ○ conte2 ○ ○ - ○ otherpc ○ ○ ○ - なお、追加したhtoc0やそのルートはホストを再起動すると失われてしまうので、起動スクリプトなどで再現する必要がある（詳細は割愛）。

概要 静的解析ツールのSonarQubeを動かしたいけど、全然今時の記事がないので備忘録がてらに。 docker-compose.ymlの設定 docker-compose.yml version: '3' services: #PHP Service app: . . . sonarqube: image: sonarqube:9.0-community depends_on: - pgsql ports: - "9000:9000" networks: - app-network environment: SONAR_JDBC_URL: jdbc:postgresql://pgsql:5432/sonar SONAR_JDBC_USERNAME: sonar SONAR_JDBC_PASSWORD: sonar volumes: - sonarqube_data:/opt/sonarqube/data - sonarqube_extensions:/opt/sonarqube/extensions - sonarqube_logs:/opt/sonarqube/logs - sonarqube_temp:/opt/sonarqube/temp pgsql: image: postgres:10 networks: - app-network environment: POSTGRES_USER: sonar POSTGRES_PASSWORD: sonar volumes: - postgresql:/var/lib/postgresql - postgresql_data:/var/lib/postgresql/data networks: app-network: driver: bridge volumes: sonarqube_data: driver: local sonarqube_extensions: driver: local sonarqube_logs: driver: local sonarqube_temp: driver: local postgresql: driver: local postgresql_data: driver: local $ docker-compose up -d localhost:9000 でアイパス共に「admin」でログインできる。 プロジェクトを作る localhost:9000/projects/create にアクセスしてプロジェクトを作成する。 ログイントークンを生成し、以下の画面まで到達する。 ローカルなのでログイントークンは公開していますが、サーバー上で動かす場合は、ログイントークンは公開しないでください ダウンロードリンクをクリックし、以下のsonar-scanner-cliのDockerでの操作方法を確認する。 https://docs.sonarqube.org/latest/analysis/scan/sonarscanner/ にて いざスキャン！ が、 $ docker run \ --rm \ -e SONAR_HOST_URL="http://${SONARQUBE_URL}" \ -e SONAR_LOGIN="myAuthenticationToken" \ -v "${YOUR_REPO}:/usr/src" \ sonarsource/sonar-scanner-cli では動かない。 Httpディレクトリをスキャンしたい場合は、以下 $ docker run \ --rm \ --net host \ -e SONAR_HOST_URL="http://localhost:9000" \ -v ${PWD}/app/Http:/usr/src \ sonarsource/sonar-scanner-cli \ -Dsonar.projectKey=test \ -Dsonar.sonar.projectName=test \ -Dsonar.sonar.projectVersion=1.0 \ -Dsonar.sonar.sourceEncoding=UTF-8 \ -Dsonar.sonar.host.url=http://localhost:9000 \ -Dsonar.login=a242986b52522d94b2b426b8f4c6de343c389487 結果 参照 Error running sonar-scanner via docker image sonarqube Doc

この記事ではDockerの基本的な概念と使い方を初学者向けに解説します。 基本的に情報は全てdocumentに書いてあるのですが、分量が多いのでミニマムで大雑把にDockerの仕組みを知りたい人向けの記事になります。初めての方がこれを読んだ後に必要なところをdocumentからつまみ食いできることを目標にします。 目次 Dockerの概要 Dockerコンテナに関するコマンド Dockerイメージに関するコマンド Dockerfileの基本的な書き方 Dockerを使うメリット Dockerを使うメリットはたくさんあると思うのですが、自分が思うDockerのメリットは 環境構築で手間取らない localのPCの環境を汚さない 他の人にすぐにコードを共有することができる といったことではないでしょうか。 Dockerの概略 Dockerを理解するポイントはDockerイメージとDockerコンテナの概念だと思います。 まず、Dockerコンテナとは実際にアプリケーションなどが動作する仮想環境です。例えば、Ruby on RailsでサーバーをDockerを使って仮想環境上で動かす時にはこのDockerコンテナの中でサーバーを起動することになります。 次にDockerイメージとはDockerコンテナを作るための設定などが書いてあるテンプレートだと考えてください。Dockerイメージを一つ作るとそこからたくさんのDockerコンテナを作ることができます。 Dockerイメージは基本的に二つの方法で入手することになります。一つ目はDocker HubというDockerイメージのライブラリ的なところからdocker pullコマンドで取得する方法。二つ目はDockerfileというDockerイメージの設計図を作成して、docker image buildコマンドで実際に自分が作りたいDockerイメージをつくる方法になります。 基本的にDockerを使うときの流れは Dockerfileからdocker buildでDocker imageを作る or Docker Hubからdocker pullでDockerイメージを持ってくる Dockerイメージからdocker container runでDockerコンテナを作る Dockerイメージを操作するコマンド 次に、Dockerイメージを操作するときの基本的なコマンドについて紹介します。 docker image build:イメージのビルド DockerfileからDockerイメージを作成する時にはこのコマンドを使います。 $ docker image build [オプション] パス | URL | - githubのリポジトリ内のから実行するときはURLを指定する Dockerfileからイメージを作る時にはDockerfileが書いてあるパスを指定する imageは省略可能 -fオプションでDockerfileの名前を指定する デフォルトだとパス/Dockerfile docker search:イメージの検索 Docker Hub内のDockerイメージを探す時にはこのコマンドを使います。 $ docker search 単語 Docker Hub内の単語が入っているDockerイメージの検索 docker pull:イメージの取得 Docker HubからDockerイメージを取得する時にはこのコマンドを使います。 $ docker pull [オプション] 名前[:タグ]|[レジストリ・ホスト[:レジストリ・ポート]/]名前[:タグ] レジストリからイメージやリポジトリを取得 docker image ls/docker images:イメージの一覧 Dockerイメージの一覧を取得するコマンドです。shellコマンドのlsのDockerバージョンになります。 $ docker images [オプション] [リポジトリ[:タグ]] -a, --all-false 全てのイメージを表示 --help 使い方の表示 -f, --filter dangling=(true|false) trueでタグ付けされていないイメージの一覧 label=<キー> or label=<キー>=<値>　label付けされたイメージの一覧 before=(<イメージ名>[:タグ]||image@digest) 指定したIDまたはまたはリファレンスより前に作成したイメージの一覧 since=(<イメージ名>[:タグ]||image@digest) 指定したIDまたはまたはリファレンスより後に作成したイメージの一覧 Docker containerを操作するコマンド 基本的なDocker containerの操作に関するコマンドを紹介します。まず初めにDockerコンテナの基本的なライフサイクルとstatusについて説明します。 Dockerコンテナにはstatusと呼ばれる状態が存在します。runningの時には起動中、exitedの場合には停止中になっています。この他にもcreatedなど他の状態もありますがここでは初めの二つのみを扱います。statusについてはdocker container ls(またはdocker ps)を用いて確認することができます。 次にDockerコンテナがどのようなライフサイクルになっているかを見てみます。 まず初めにdocker runコマンドによってDockerイメージからDockerコンテナが作られます。このとき、できたコンテナは自動的に起動中(running)になります。 起動中(running)であるコンテナにdocker stopコマンドを使うとstatusは停止中(exited)になります。 ただし、バックグラウンド実行などのオプションがついてないときは起動中(running)になってすぐに停止(exited)することがあります。停止中(exited)中のコンテナにdocker restartを使うと起動中(running)にすることができます。 最後に停止中のDockerコンテナに対してdocker rmコマンドを使うとDockerコンテナを削除することができます。 docker container run:DockerイメージからDockerコンテナを作成と実行 DockerイメージからDockerコンテナを作成するコマンドになります。また、Dockerコンテナの実行も行います。 $ docker run [オプション] イメージ[:タグ|@ダイジェスト値] [コマンド] [引数...] containerは省略可能 -pでポート番号を指定する(e.g. -p 9000:8080でDockerコンテナ内で9000番のポート番号とコンテナ外の環境でのポート番号8080を同期している。 -dでデタッチドモード(バックグラウンド)で実行。デフォルトだとフォアグラウンドで実行 --rmで終了したコンテナの削除を自動で行う docker container ls:Dockerコンテナの一覧の取得 Dockerコンテナの一覧を取得するコマンドです。 $ docker container ls [オプション] -aで停止しているコンテナも表示する 表示されるコンテナの絞り込みや情報については多くのオプションがあるのでドキュメントで確認してください。 docker container stop:コンテナの停止 Dockerコンテナの停止を行うコマンドです。コンテナの削除を行うときは一度停止する必要があるので注意は必要です。 $ docker stop [オプション] コンテナ [コンテナ...] docker container restart:コンテナの再起動 Dockerコンテナの再起動を行うコマンドです。一度停止したコンテナの再起動を行います。 $ docker restart [オプション] コンテナ [コンテナ...] docker container rm:コンテナの破棄 停止中のDockerコンテナの削除を行います。停止中でないとできないことに注意が必要です。 $ docker rm [オプション] コンテナ [コンテナ...] docker container exec:実行中のコンテナでのコマンド実行 実行中のコンテナ内で、新しいコマンドを実行します。 docker exec [オプション] コンテナ コマンド [引数...] -d コマンドをデタッチドモード(バックグラウンド)で実行 -itでコンソールに結果を出力する。基本的につけておいたほうがいい。 以下のコマンドで実際に起動中のコンテナに直接入る(入ったかのような作業を行う)ことができます。 $ docker exec -d -it コンテナ bash Dockerfileの書き方 Dockerイメージを作成するための設計図となるDockerfileの書き方を簡単に紹介します。 FROM 基本的に一番初めに書くべきコードでベースとなるDockerイメージを選択します。ここで選んだimage上でこれ以降の操作は動いて行きます。 以下のコマンドでbaseイメージをDocker Hubから取得します。 FROM baseイメージ 具体例としては FROM ubuntu:18.04 でubuntuの18.04versionが取得します。 RUN ここにはイメージ上で環境構築のために実行したいコマンドを書いていきます。例えば、ライブラリのインストールやgithubからのファイルの取得などができます。 baseの環境内で自動的に実行するコマンドを書いていきます。ライブラリのインストールなどの環境構築に関連するコマンドをここで書いていきます。 RUN コマンド 例えば、pipを使ってqutipというライブラリをDocker環境内にインストールする時には RUN pip install qutip とします。 COPY ここにはDockerコンテナの外部のファイルをDockerコンテナ内にコピーすることができます。これによってDocker外部で作ったファイルを仮想環境の内部に持っていくことができます。 以下のように書くことで今いるディレクトリにあるsample.pyをDocker内のPATHにコピーします。 COPY sample.py PATH CMD Docker環境を作成したのちに、Dockerコンテナ内でプログラムを実行するときに使います。具体的にはDockerコンテナ内のsample.pyというpythonコードを実行する時には次のように書くことができます。 CMD ["python", "sample.py"] コマンドの一つ一つを""で囲って、カンマで区切って[ ]内に書くだけで大丈夫です。 ここであげた以外にもコマンドはあるので調べてみてください。 参考文献 Docker公式document - https://docs.docker.jp/index.html 最後に Dockerを使いこなすにはDocker自体の知識だけではなくLinuxやshell、ネットワークなどの環境構築に関する様々な知識が必要になってくると思います。 みなさんの知識の復習や学習も兼ねて触っていくと楽しめると思います。 余裕がありましたら続編を書いてみたいと思っています。 間違っているところや、質問などがありましたらコメントよろしくお願いします。

Docker上のみでシステムを作るときの構成 https://qiita.com/official-events/339b6440dbd578f4f66f 参加記事を書こうと思った。 あなたもdocker, 私もdocker https://qiita.com/kaizen_nagoya/items/8f2746f10f30b575d0a8 の記事を書きながらdockerを動かしていて出たエラー 今日のdocker error :Error response from daemon: conflict: unable to delete bash $ docker images REPOSITORY TAG IMAGE ID CREATED SIZE gcc latest 011376e71a26 31 hours ago 1.23GB continuumio/anaconda3 latest 6ed36b0faac9 2 days ago 2.8GB $ docker rmi 011376e71a26 Error response from daemon: conflict: unable to delete 011376e71a26 (must be forced) - image is being used by stopped container 261cd42516ec $ docker stop 261cd42516ec 261cd42516ec $ docker rmi 011376e71a26 Error response from daemon: conflict: unable to delete 011376e71a26 (must be forced) - image is being used by stopped container 261cd42516ec $ docker rmi 6ed36b0faac9 Error response from daemon: conflict: unable to delete 6ed36b0faac9 (must be forced) - image is being used by stopped container 7186dd476e26 $ docker stop 7186dd476e26 7186dd476e26 $ docker rmi 6ed36b0faac9 Error response from daemon: conflict: unable to delete 6ed36b0faac9 (must be forced) - image is being used by stopped container 7186dd476e26 stopしてもだめやん。

Landoでlocal環境を作って壊す作業を繰り返しているとそれも手間と感じる。 いろんなアプリ環境を試したりDrupalをバージョンごとに複数環境を置きたい場合もある。 Drupal9で試す場合 $ composer create-project drupal/recommended-project dev1 && cd dev1 Drupal8や古いバージョンを試したい時は、少しインストールの仕方が違います。 $ mkdir dev1 && cd dev1 $ lando init \ --source remote \ --remote-url https://ftp.drupal.org/files/projects/drupal-8.9.0.tar.gz \ --remote-options="--strip-components 1" \ --recipe drupal8 \ --webroot . \ --name dev1 .lando.ymlを各ディレクトリに用意します。 .lando.yml $ touch .lando.yml $ vim .lando.yml recipe:　はdrupalのバージョンにします。 portforward: のポート番号は重複不可なので番号をズラします。 .lando.yml name: dev1 recipe: drupal9 config: webroot: web php: '7.4' services: appserver: build_as_root: - apt update -y && apt-get install vim -y dev1db: type: mysql:5.7 portforward: 33070 lando start http://dev１.lndo.site/でアクセスすると並行起動してもログインが維持される。 NAME dev1 LOCATION /Users/*****/lando/dev1 SERVICES appserver, database, dev1db APPSERVER URLS https://localhost:54217 http://localhost:54218 http://dev1.lndo.site/ https://dev1.lndo.site/ databaseの確認 hostはdev1db database名はdatabase userとpasswordはmysql をインストール時に使います。 lando.info [ { service: 'appserver', urls: [ 'https://localhost:54217', 'http://localhost:54218', 'http://dev1.lndo.site/', 'https://dev1.lndo.site/' ], type: 'php', healthy: true, via: 'apache', webroot: 'web', config: { php: '/Users/*****/.lando/config/drupal9/php.ini' }, version: '7.4', meUser: 'www-data', hasCerts: true, hostnames: [ 'appserver.dev.internal' ] }, { service: 'database', urls: [], type: 'mysql', healthy: true, internal_connection: { host: 'database', port: '3306' }, external_connection: { host: '127.0.0.1', port: '54216' }, healthcheck: 'bash -c "[ -f /bitnami/mysql/.mysql_initialized ]"', creds: { database: 'drupal9', password: 'drupal9', user: 'drupal9' }, config: { database: '/Users/*****/.lando/config/drupal9/mysql.cnf' }, version: '5.7', meUser: 'www-data', hasCerts: false, hostnames: [ 'database.dev.internal' ] }, { service: 'devdb', urls: [], type: 'mysql', healthy: true, internal_connection: { host: 'dev1db', port: '3306' }, external_connection: { host: '127.0.0.1', port: '33070' }, healthcheck: 'bash -c "[ -f /bitnami/mysql/.mysql_initialized ]"', creds: { database: 'database', password: 'mysql', user: 'mysql' }, config: {}, version: '5.7', meUser: 'www-data', hasCerts: false, hostnames: [ 'devdb.dev.internal' ] } ] Drupalインストール database名はdatabase userとpasswordはmysql 高度なオプションで hostはdev1db でインストールは完了です。

Docker上のみでシステムを作るときの構成 https://qiita.com/official-events/339b6440dbd578f4f66f 参加記事です。 普段はmacOSHigh Sierra ver. 10.13.6 メモリ16GB, intel Core i5 HDD 250GB, 空 6GB です。 docker(0) 資料集 [あなたもdocker私もdocker] https://qiita.com/kaizen_nagoya/items/45699eefd62677f69c1d に１４０ほど記事を書いています。 dockerで実現したいことが似ている場合は、そちらを参照くださると幸いです。 gcc dockerの使い道の1つ目は、gcc. macOSでgccのクロスコンパイラをコンパイルしようとして１日かけてもうまく行かず、斉藤直希さんに相談し、docker上でgccクロスコンパイラを構築してもらった。 Dockerをどっかーらどうやって使えばいいんでしょう。TOPPERS/FMP on RaspberryPi with Macintosh編 ５つの関門「名古屋のIoTは名古屋のOSで」docker (37) https://qiita.com/kaizen_nagoya/items/9c46c6da8ceb64d2d7af gccだけ使いたい場合は、 bash $ docker run -it gcc /bin/bash 例えば、 Misra Example Suite at docker コンパイル完了までの道のり。docker(200) https://qiita.com/kaizen_nagoya/items/71f04a0204d5a1114577 python dockerの使い道の2つ目は、python. 機械学習の教育の助手を担当して、Windowsにpytohnを導入するのに失敗した人たちが大勢いて、落ちこぼれの原因がpython導入であることがわかった。 M.S.WindowsにPython3 (Anaconda3) を導入する（7つの罠） https://qiita.com/kaizen_nagoya/items/7bfd7ecdc4e8edcbd679 自分のQiitaの記事で、viewsが圧倒的に一番で、161987 viewsある。 二番目が プログラマが知っているとよい色使い(JIS安全色) https://qiita.com/kaizen_nagoya/items/cb7eb3199b0b98904a35 の82114 viewsだから約倍。 その後、dockerにPythonを導入してもらう方が楽かなって思うようになった。 docker(18) なぜdockerでpython/Rを使って機械学習するか 書籍・ソース一覧作成中 (目標100) https://qiita.com/kaizen_nagoya/items/ddd12477544bf5ba85e2 dockerに書籍のソースコードを読み込んで、動かす実験を順次してきた。 言語学習 pythonの言語教育を担当することになり、python のいろいろな版を利用するには、dockerが最適であると感じた。 pyenvなど、いろいろなpythonの複数の版を切り替える方法は面倒くさいだけでなく、python 初心者に使い方を教える時間が無駄だと感じた。 bash $ docker run -it continuumio/anaconda3 /bin/bash 言語処理100本ノックは、こちらの記事から参考にしてみてください。 言語処理100本ノック 2015(python) 落ち穂拾い 第1章: 準備運動 https://qiita.com/kaizen_nagoya/items/ee1b625b0b65cd63d42a 英語辞書作成 dockerの使い道の３つ目は、英語の文献を読んで単語帳を作る時。 「量子アニーリングの基礎」を読む勉強会を開催した。 「量子アニーリングの基礎」を読む https://qiita.com/kaizen_nagoya/items/29580dc526e142cb64e9 で参考文献の半分以上が英語論文だった。順次単語帳を作った。 プログラムちょい替え（10）英語(14) 単語帳作成 dockerで（文字コード対応）量子計算機　arXiv掲載　西森 秀稔　論文(shell, awk), docker(82) https://qiita.com/kaizen_nagoya/items/319672853519990cee42 この時は、素のubuntuから始める。 bash $ docker run -it ubuntu /bin/bash dockerが起動したら bash # apt install -y poppler-utils vim 更新 どの場合も、dockerが立ち上がったら、 bash # apt update; apt -y upgrade をまずしよう。 全部で300くらいdockerを使った記事を書いているような気がする。 エラーがあった時に、検索する場合、　docker kaizen_nagoyaの文字を入れるとずばりヒットするかも。docker関連のエラーをなるべく記事にしています。 困りごと 1. loginできない。 アプリは起動し、メニューからloginしているはずなのに、 dockerコマンド打つと、loginしてないと怒られることがある。 コマンドで、docker login し直すといいことがある。 それでも駄目な時は、OSを再起動して、dockerアプリでログインし、 コマンドでもloginするといいことがある。MS Windowsでも類似の経験あります。 docker(80)「DockerでPHP7.0×Apacheの環境を構築する@kurkuru」IT業界新人利用時の１6の壁(mac mini編） https://qiita.com/kaizen_nagoya/items/315e8d05a6eef00b56d1 2. run, pushできない 自分の経験では綴りがちがっていることが一番多い。 anaconda3ではだめで、continuumio/anaconda3じゃないといけないみたいに全部指定しないと駄目なことがある。 その次には、同じ名前で作業していたりとか。 docker(17) docker入門の入門　５つの壁 https://qiita.com/kaizen_nagoya/items/e73ceab051a5556a652c 3. ブラウザで確認したい。 今回の趣旨とは少しずれるかもしれないが、 dockerで動作させたものを、ブラウザで確認したいことがしばしばある。 python でjupiter notebookを使うときや、 javascript, PHPなどで作ったソフトを確かめる時など。 4. HDD等の空きがない。 dockerをいっぱい立ち上げてrm, rmiするといいかも。 docker(9) rmiのための順番 https://qiita.com/kaizen_nagoya/items/0bc05d08cf18af4a8801 5. メモリが足りない 機械学習などをしているとdockerに10GB以上割り当ててないと、処理が進まないことがある。本体を32GBメモリにしてdockerに24GB割り当てると結構楽かも。 この作業のエラー 今日のdocker error :Error response from daemon: conflict: unable to delete https://qiita.com/kaizen_nagoya/items/a486385d6af636c98f0a 参考資料 プログラミング言語教育のXYZ。Youtube(1) 仮説・検証（52） https://qiita.com/kaizen_nagoya/items/1950c5810fb5c0b07be4

はじめに このシリーズでは、コンテナ化されたアプリケーションをRed Hat OpenShift上にデプロイする流れについて調査した内容を整理していこうと思います。 OpenShiftはKubernetesをベースとしてエンタープライズ向けに各種機能が拡張されており、アプリケーションのデプロイ部分についても多くの有用な機能が提供されています。特にアプリケーション(コンテナ)をOpenShiftクラスターにデプロイするためのoc new-appコマンドではかなり強力な機能が提供されていますが、反面、様々なことができすぎて何をやっているのか理解するのがかなり困難でした。ここでは自分なりの理解を整理していきたいと思います。 最初は本題に入る前のおさらいとして、OpenShift環境ではない場合のDocker環境について前提となる考え方を整理しておきます。 関連記事 Red Hat OpenShift Study / コンテナのデプロイ - (0) Dockerおさらい Red Hat OpenShift Study / コンテナのデプロイ - (1) Dockerイメージを元にしたデプロイ Red Hat OpenShift Study / コンテナのデプロイ - (2) Dockerビルド Red Hat OpenShift Study / コンテナのデプロイ - (3) s2i ビルド Docker関連用語の整理 コンテナ利用時のざっくりとした概要図 主要な登場人物はこちら。 Dockerコンテナ: Dockerイメージを基にして作成される仮想環境のインスタンスです。コンテナが稼働することでミドルウェアやアプリケーションのサービスを提供します。 Dockerイメージ: Dockerコンテナの元になるイミュータブルな情報の塊です。カーネルより上のミドルウェアやアプリケーション・モジュールなどが組み込まれています。 Dokcerイメージはその内容によって様々な用途で使用されます。 例えばmysqlやnginxなどのミドルウェアが稼働できるようにしたDockerイメージというのは多数提供されており、そのようなイメージを使うと構成パラメーターなどを与えることですぐにサービスを利用開始できます。 あるいは、最小限のOSパッケージのみ提供した、他のDockerイメージを作成する際のベースとなるようなものも提供されています。これを使って独自のアプリケーションを組み込んだDockerイメージをビルドすることができます。 また、後々取り上げますが、アプリケーションのコンパイラなどを組み込んだいわゆる開発環境として利用するためのDockerイメージというのもあります。これは"ビルダー・イメージ"と呼ばれたりします。(これはOpenShiftでは非常に重要です！) Dockerリポジトリ: Dockerイメージは通常Dockerレジストリというサーバー上で管理されます。この時、Dockerイメージはタグ付けされてバージョン管理されるので、同じ内容の異なるDockerイメージ(異なるバージョン)の集合を、リポジトリという単位で管理されることになります。 "リポジトリ名"と"イメージ名"はほぼ同義的に使われていることも多く、当記事でもあまり厳密には区別していませんが、レジストリの管理単位を意識する際は"リポジトリ名"、それ以外は"イメージ名"と記載することが多いと思います。 Dockerレジストリ: Dockerリポジトリを集約して管理しホスティング機能を提供するサービスです。 インターネット上で利用できるサービスとしては、Docker Hub(イメージを参照する時のデフォルトの参照先として利用される)や、Red Hat Container Registry(Red Hatが管理しているレジストリー。参考) 、Quay.io、GitLab.com などがあります。 また、インターネット上で提供されるサービスではなく、セキュアな環境に独自にDockerレジストリのサーバーを立てるということも可能で、GitLab Container RegistryやSonatype Nexus Repositoryなど色々選択肢もあるようです。ちなみにOpenShift内にも内部レジストリを保持しています。 Dockerイメージを扱う場合、Dockerイメージは以下のような書式で表されます。 <レジストリ名>/<イメージ名>:<タグ名> レジストリ名とタグ名は省略可能で、省略した場合通常はデフォルトでレジストリ名はdocker.io(DockerHub)、タグ名はlatestが使われます。例えばdockerコマンドで、 docker pull centos というコマンドを実行した場合、centos 部分は正確にはdocker.io/centos:latestと解釈されます。(docker.io/centosはコチラです。) 上の例はイメージ名がシンプルにcentosという名前でしたが、前段に名前空間が付くものもあります。例えばansible/centos7-ansible(コレ)といった感じです。このイメージをpullしたい場合は以下のような書き方になります。いずれも同義です。 docker pull ansible/centos7-ansible docker pull ansible/centos7-ansible:latest docker pull docker.io/ansible/centos7-ansible:latest 名前空間が無いものはDockerHubが公式に公開しているDockerイメージで、名前空間が付いているものはその名前空間のユーザーが提供しているDockerイメージです。例えばDockerHubにtomotagworkというユーザーを作ってそこにDockerイメージをアップロードすると、tomotagwork/xxxというイメージ名でアクセスすることになります。 OpenShiftクラスターにアプリケーションをデプロイする場合、どのレジストリのイメージをベースにどうやって新たなイメージをビルドして、それをどこのレジストリで管理するか、みたいなことは必ずついて回るのでこの辺りの関係性はきちんと把握しておく必要があります。 Dockerイメージのビルド あるサービスをコンテナとして稼働させようとする場合、出来合いのDockerイメージをそのまデプロイすればOKということにはならないので、なんらかのカスタマイズを加えたりアプリケーションを組み込んだりしてDockerイメージをビルドし、それを利用することが普通です。 流れを図示するとこんな感じになると思います。 Dockerイメージのビルドの例は別の記事でシンプルな例を記載しているのでそちらもご参照ください。 参考: コンテナ型仮想化技術 Study01 / Docker基礎 - Dockerイメージ作成 Dockerイメージをビルドする場合、Dockerfileでビルド時に実行する内容を指定します。 上のリンク先の例のDockerfileを再掲します。 FROM golang:1.9 RUN mkdir /echo COPY main.go /echo CMD ["go", "run", "/echo/main.go"] FROMでベースとなるDockerイメージを指定します。上の例ではDockerHub上に提供されるgolang:1.9というDockerイメージをベースとして使うことになります。これはGo言語の実行環境が提供されるDockerイメージです。 RUNやCOPYなどを使用してベースとなるDockerイメージ対するカスタマイズ内容を記載します。上の例では、Dockerイメージ内に/echoというディレクトリを作成し、ローカルの環境のmain.goというファイル(Goのソース)をDockerイメージ内の/echoディレクトリにコピーしています。 CMDでは、コンテナ起動時に実行されるコマンドを記載しておきます。 このDockerfileと動かしたいGOのソース(main.go)を作成して'docker build'コマンドを実行すると、最終目的のDockerイメージがビルドできます。それをdocker runで実行すれば、コンテナ上でmain.goが実行されるということになります。 これは非常に単純なGo言語の例でしたが、Javaなどコンパイルを行う必要があるケースや、node.jsなど依存関係のあるモジュールをダウンロードするプロセスが必要なケース、あるいは特殊なOSパッケージが必要であればそれをyumでインストールする必要があるケースなどもあります。その場合、Dockerfileがもっと複雑になったり、処理をスクリプト化して与えてあげる必要があります。 Dockerfile - ONBUILD Dockerイメージは基本的には他のイメージを元にカスタマイズしていくものなので親子関係が生じます。この親子関係に大きく依存する機能としてDockerfileの書き方でONBUILDというコマンドがあります。これが指定されたコマンドはそのDockerfileのビルド時ではなく、そこで生成されたイメージをベースとして子のイメージをビルドする際に実行されます。 具体的にやってみます。 親のイメージをビルド Dockerfile(親) FROM golang:latest RUN mkdir /test ONBUILD COPY main.go /test CMD ["go", "run", "/test/main.go"] 親イメージのビルド # docker build -t goparent . Sending build context to Docker daemon 2.048kB Step 1/4 : FROM golang:latest ---> b09f7387a719 Step 2/4 : RUN mkdir /test ---> Using cache ---> 75cb335614e4 Step 3/4 : ONBUILD COPY main.go /test ---> Running in 2c0ac4735863 Removing intermediate container 2c0ac4735863 ---> 2a88949a0ca8 Step 4/4 : CMD ["go", "run", "/test/main.go"] ---> Running in d56f92f651e8 Removing intermediate container d56f92f651e8 ---> ef8f087ededa Successfully built ef8f087ededa Successfully tagged goparent:latest イメージがビルドされました。 イメージ確認 # docker images REPOSITORY TAG IMAGE ID CREATED SIZE goparent latest ef8f087ededa 2 minutes ago 862MB ... docker historyで、そのイメージに対して行われた変更の内容を確認できます。ここでONBUILDコマンドも確認できます。ONBUILDで指定したコマンドはこの親イメージのビルド時には実行されていません。従って、親イメージのビルド時にはmain.goファイルは不要です。(以下の表示だとコマンドの後ろが切れてしまっていますが、--no-truncオプションを付けると省略されずに表示されます。) イメージのhistory確認 # docker history goparent:latest IMAGE CREATED CREATED BY SIZE COMMENT ef8f087ededa 3 minutes ago /bin/sh -c #(nop) CMD ["go" "run" "/test/ma… 0B 2a88949a0ca8 3 minutes ago /bin/sh -c #(nop) ONBUILD COPY main.go /test 0B 75cb335614e4 13 minutes ago /bin/sh -c mkdir /test 0B b09f7387a719 9 days ago /bin/sh -c #(nop) WORKDIR /go 0B <missing> 9 days ago /bin/sh -c mkdir -p "$GOPATH/src" "$GOPATH/b… 0B <missing> 9 days ago /bin/sh -c #(nop) ENV PATH=/go/bin:/usr/loc… 0B <missing> 9 days ago /bin/sh -c #(nop) ENV GOPATH=/go 0B <missing> 9 days ago /bin/sh -c set -eux; dpkgArch="$(dpkg --pr… 386MB <missing> 9 days ago /bin/sh -c #(nop) ENV GOLANG_VERSION=1.16.5 0B <missing> 4 weeks ago /bin/sh -c #(nop) ENV PATH=/usr/local/go/bi… 0B <missing> 4 weeks ago /bin/sh -c apt-get update && apt-get install… 182MB <missing> 4 weeks ago /bin/sh -c apt-get update && apt-get install… 146MB <missing> 4 weeks ago /bin/sh -c set -ex; if ! command -v gpg > /… 17.5MB <missing> 4 weeks ago /bin/sh -c set -eux; apt-get update; apt-g… 16.5MB <missing> 4 weeks ago /bin/sh -c #(nop) CMD ["bash"] 0B <missing> 4 weeks ago /bin/sh -c #(nop) ADD file:1a1eae7a82c66d673… 114MB ※後述のpodmanコマンドを使う場合、ONBUILDが含まれているDockerfileをビルドするためには--format dockerオプションを指定する必要があります(ONBUILDはOCIという標準に含まれていないため)。 子のイメージをビルド ここでは親イメージをRegistryにはアップせずに、そのままローカルのDocker環境にあるものを使用します。FROM以外は特に何も指定しません。 Dockerfile(子) FROM goparent:latest 親イメージビルド時に、main.goファイルをDockerイメージ内にコピーするようONBUILDで指定されているので、main.goファイルを用意しておきます。 main.go package main import ( "fmt" "log" "net/http" ) func main(){ http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request){ log.Println("received request") fmt.Fprintf(w, "Hello Docker!") }) log.Println("start server") server := &http.Server{Addr: ":8080"} if err := server.ListenAndServe(); err != nil { log.Println(err) } } ビルドします。 # docker build -t gochild . Sending build context to Docker daemon 3.072kB Step 1/1 : FROM goparent:latest # Executing 1 build trigger ---> d2bb1b8ee97e Successfully built d2bb1b8ee97e Successfully tagged gochild:latest コンテナを稼働させて確認してみます。 # docker run -d -p 8080:8080 gochild 75f586a4717bb269aae84e0b7e2cf85afd43f4d77089b99bee6a191ab788cf84 # curl localhost:8080 Hello Docker! きちんと親イメージのビルド時に指定されたONBUILDが子イメージのビルド時に実行されました！ ここで実施した操作を図示するとこんな感じです。 podmanコマンド コンテナ管理用の仕組みとしてdockerに代わるpodmanというコマンドが提供されており、Red Hatはpodmanの利用を推奨しているようです。dockerと違いpodmanはデーモンを稼働させておかなくてもコンテナを扱うことができます。podman build、podman runなどdockerと同じ体系のコマンドがおぼそのまま使えますし、一部Kubernetes/OpenShiftのPodの単位を簡易的に取り扱うこともできるので、OpenShiftを扱う場合にはpodmanを併用すると使い勝手がよいと思います。 参考: podman skopeoコマンド OpenShiftでコンテナを扱う場合、基本的には元になるDockerイメージはレジストリ上に管理しておく必要があります。DockerイメージのビルドはどこかのLinux環境でPodmanやDockerを使って行われるので、Dockerイメージをレジストリにアップしたりすることが必要になりますが、そこで使用できるのがskopeoコマンドです。 参考: skopeo skopeo copyコマンドを使用すると、レジストリ-ローカル環境間でDockerイメージのコピーができます。Dockerイメージの形式はいくつかあるのでその形式ごとに指定の仕方が異なります。 認証が必要なレジストリにアクセスする場合は、事前にpodman loginでレジストリにログインしておく必要があります(docker loginでも可)。 また、レジストリ上で別のタグにコピーすることも可能です。 skopeo inspectコマンドを使用すると、Dockerイメージの情報が確認できます。 inspect実行例 # skopeo inspect docker://docker.io/library/httpd:latest { "Name": "docker.io/library/httpd", "Digest": "sha256:48bae0ac5d0d75168f1c1282c0eb21b43302cb1b5c5dc9fa3b4a758ccfb36fe9", "RepoTags": [ "2-alpine", ... "2.4", "2", "alpine", "latest" ], "Created": "2021-05-26T00:23:59.233513625Z", "DockerVersion": "19.03.12", "Labels": null, "Architecture": "amd64", "Os": "linux", "Layers": [ "sha256:69692152171afee1fd341febc390747cfca2ff302f2881d8b394e786af605696", "sha256:7284b4e0cc7b197edc206f815c5b24e67b9ed29abd9bbd8ae4bfdd5540bec6ec", "sha256:3678b2d55ccdc6dcbe11cf1ea518ab7426ab37656d94213f637bd843dc6b6ca4", "sha256:aeb67982a725b5d6e8a2b3114d1bc8ca4aaadb6b6797614b6831cd6703260768", "sha256:06954f8169fdab8e97f3e61ee1090df58c3362b8a4d00160d3da53ef6577b131" ], "Env": [ "PATH=/usr/local/apache2/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin", "HTTPD_PREFIX=/usr/local/apache2", "HTTPD_VERSION=2.4.48", "HTTPD_SHA256=1bc826e7b2e88108c7e4bf43c026636f77a41d849cfb667aa7b5c0b86dbf966c", "HTTPD_PATCHES=" ] } おわりに とりあえずOpenShift環境以外の一般的なDocker環境での基本的な考え方をおさらいでした。OpenShiftでの操作は複雑なので混乱した時に立ち返る場所として整理しておきました。 次回から本題に入っていきます。

Djangoのrunserverコマンドで動かすサーバーは、あくまで簡易的な開発用サーバーです。本番運用する場合にはセキュリティやパフォーマンスの観点からWebサーバー（リバースプロキシ）とApplicationサーバー（WSGIサーバー）を別途構築する必要があります。 今回、WebサーバーにはNginxを、アプリケーションサーバーにはGunicornを用いてDocker上に構築します。 環境 ソフト バージョン OS MacOS Catalina 10.15.7 docker engine 20.10.5 docker compose 1.29.0 Django 3.2.5 Gruncorn 20.1.0 Nginx 1.17.7 ディレクトリ構成 . ├── app # Djangoアプリ ├── config # Django設定関係 │ ├── local_settings.py │ ├── settings.py │ ├── Dockerfile ├── docker-compose.yml ├── docker.env ├── gunicorn.conf ├── manage.py └── requirements.txt Django設定ファイル 開発環境用にlocal_settings.pyファイルを作成し、'SECRET_KEY'、'DEBUG'、'ALLOWED_HOSTS'のデフォルト設定はそちらに移行。 開発用サーバーを起動する際には、settingsオプションで'local_settings.py'ファイルを指定する。 config/local_settings.py from .settings import * SECRET_KEY = 'XXXXX' DEBUG = True ALLOWED_HOSTS = [] # 開発用サーバ起動コマンド # python manage.py runserver --settings config.local_settings settings.pyファイルには本番環境設定を記述する。'SECRET_KEY'、'ALLOWED_HOSTS'は環境変数からの引用とし、'DEBUG'はFalseにする。 config/settings.py SECRET_KEY = os.environ.get('DJANGO_SECRET_KEY') DEBUG = False ALLOWED_HOSTS = os.environ.get('ALLOWED_HOSTS') Dockerファイルの設定 Dockerコンテナ内にpython環境を構築し、requirements.txtで定義したDjangoとGunicornをインストール。 gunicornコマンドでGunicornを起動し、config/wisg.pyを読み込み、UNIXドメインソケットをバインドする。 Dockerfile FROM python:3.9.6-alpine WORKDIR /usr/src/app ENV PYTHONDONTWRITEBYTECODE 1 ENV PYTHONUNBUFFERED 1 RUN pip install --upgrade pip COPY ./requirements.txt /usr/src/app/requirements.txt RUN pip install -r requirements.txt RUN mkdir -p /var/run/gunicorn CMD ["gunicorn", "config.wsgi", "--bind=unix:/var/run/gunicorn/gunicorn.sock"] requirements.txt Django==3.2.5 gunicorn==20.1.0 Docker Composeファイルの設定 gunicornイメージはDockerファイルからbuildし、nginxイメージはDocker Hubからダウンロードする。 gunicornコンテナ、nginxコンテナの双方でgunicronボリュームにマウントし、UNIXソケット通信を行う。 コンテナ内のnginx設定ファイル（default.conf）をホスト側で作成したgunicorn.confファイルにマウントする。 Djangoアプリの'DJANGO_SECRET_KEY'と'ALLOWED_HOSTS'は環境変数として設定する。 docker-compose.yml version: '3' services: gunicorn: build: . image: gunicorn:20.1.0 container_name: gunicorn volumes: - .:/usr/src/app/ - gunicorn:/var/run/gunicorn env_file: docker.env nginx: image: nginx:1.17.7 container_name: nginx depends_on: - gunicorn ports: - "80:80" volumes: - ./gunicorn.conf:/etc/nginx/conf.d/default.conf - gunicorn:/var/run/gunicorn volumes: gunicorn: driver: local gunicorn.conf upstream gunicorn-django { server unix:///var/run/gunicorn/gunicorn.sock; } server { listen 80; server_name localhost; location / { try_files $uri @gunicorn; } location @gunicorn { proxy_pass http://gunicorn-django; } } docker.env DJANGO_SECRET_KEY='XXXXX' ALLOWED_HOSTS=['XXX.XXX.XXX.XXX'] 起動コマンド docker-compose upコマンドでコンテナを生成・起動する。 localhostにアクセスし画面が出ればOK $ docker-compose up -d 参考 DockerでPythonのWebアプリケーションをNginx + Gunicorn で起動する

はじめに 今回は，ESXi上にUbuntuのVMを建ててKubernetes (K8s) 環境の構築をしてみました． クラスター構築ツールにはkubeadm，CNIプラグインにはCalico，CRIにはDockerを利用しました． 詳細は下記のリストを参照してください． マシンスペック: CPU: 2 vCPU RAM: 2 GB OS: Ubuntu 20.04.2 LTS Docker: 20.10.7 kubelet: 1.21.2 kubeadm: 1.21.2 kubectl: 1.21.2 calicoctl: 3.19.1 K8sのNodeになる各マシンにUbuntuのインストールまでが完了している状態から開始します．この時点で，すべてのマシンに対してDDNSによってドメイン名が割り当てられています． 基本的には，Kubernetesの公式ドキュメントに従って進めていきます． kubeadm, kubelet, kubectl のインストール kubeadmを導入しないことには，K8sクラスターの構築は始まりません．kubeadmのインストールのページのとおりにインストールを進めます． 要件 「始まる前に」の節にホストマシンの満たすべき要件が記されています．ドキュメントでは確認方法がほどんど省かれているので細かめに書いておきます． OS 今のところ，OS（というよりディストリビューション）は下記リストのいずれかである必要があるようです． Ubuntu 16.04+ Debian 9+ CentOS 7 Red Hat Enterprise Linux (RHEL) 7 Fedora 25+ HypriotOS v1.0.1+ Container Linux (tested with 1800.6.0) Ubuntuであれば， $ cat /etc/os-release NAME="Ubuntu" VERSION="20.04.2 LTS (Focal Fossa)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu 20.04.2 LTS" VERSION_ID="20.04" HOME_URL="https://www.ubuntu.com/" SUPPORT_URL="https://help.ubuntu.com/" BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/" PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy" VERSION_CODENAME=focal UBUNTU_CODENAME=focal のようにして確認できます． CPU・メモリ CPUのコア数は， /proc/cpuinfo にコア毎の情報が書かれているので，それを利用して processor の項目がいくつあるかを数えることで求められます． メモリ容量は free コマンドで確認できます． $ fgrep 'processor' /proc/cpuinfo | wc -l 2 $ free -m total used free shared buff/cache available Mem: 1987 508 258 2 1221 1305 Swap: 0 0 0 マシン間の疎通確認 pingをうてばよかろうなのだ．xxxには疎通確認したいマシンのhostnameが入ります． $ ping xxx PING xxx (192.168.100.88) 56(84) bytes of data. 64 bytes from 192.168.100.88 (192.168.100.88): icmp_seq=1 ttl=64 time=0.166 ms 64 bytes from 192.168.100.88 (192.168.100.88): icmp_seq=2 ttl=64 time=0.227 ms 64 bytes from 192.168.100.88 (192.168.100.88): icmp_seq=3 ttl=64 time=0.170 ms 64 bytes from 192.168.100.88 (192.168.100.88): icmp_seq=4 ttl=64 time=0.165 ms ^C --- xxx ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3043ms rtt min/avg/max/mdev = 0.165/0.182/0.227/0.026 ms ユニークなhostname，MACアドレス，product_uuid hostnameは hostname コマンド，MACアドレスは，ip link コマンド，product_uuid は sudo cat /sys/class/dmi/id/product_uuidコマンドで確認できます． 自分は，ローカルのエディタに張り付けて目視で重複のないことを確認しました．マシンの数が多くなれば別の方法を考えたほうが良いかもしれません． ポート開放 今回はファイアウォールがOFFなので省略✌． SwapがOFF デフォルトだとONになっていると思います．swapoff -aコマンドでOFFにします．サーバ再起動後もSwapをOFF状態にしておくために，/etc/fstab のswap.imgの行をコメントアウトしておきます． それ以降 これ以降のセットアップは，全部のコマンドが貼り付けられたシェルスクリプトを用意して，管理者権限で実行すると楽なのでおすすめです． ひとまず，1つのマシンでだけ１つづつ進めていって動作の確認をしておきましょう． iptablesの設定をして，Dockerのセットアップ，kube*のインストールをするまでの全部入りの雑スクリプト（ただのコピペ）を置いておきます． # iptables関連の設定 modprobe br_netfilter cat <<EOF > /etc/sysctl.d/k8s.conf net.bridge.bridge-nf-call-ip6tables = 1 net.bridge.bridge-nf-call-iptables = 1 EOF sysctl --system sudo apt-get install -y iptables arptables ebtables sudo update-alternatives --set iptables /usr/sbin/iptables-legacy sudo sudo update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy sudo update-alternatives --set arptables /usr/sbin/arptables-legacy sudo update-alternatives --set ebtables /usr/sbin/ebtables-legacy # Dockerのインストール apt-get update && apt-get install -y \ apt-transport-https ca-certificates curl software-properties-common gnupg2 curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - add-apt-repository \ "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) \ stable" apt-get update && apt-get install -y \ containerd.io=1.2.13-2 \ docker-ce=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) \ docker-ce-cli=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) cat > /etc/docker/daemon.json <<EOF { "exec-opts": ["native.cgroupdriver=systemd"], "log-driver": "json-file", "log-opts": { "max-size": "100m" }, "storage-driver": "overlay2" } EOF mkdir -p /etc/systemd/system/docker.service.d systemctl daemon-reload systemctl restart docker systemctl enable docker # kubelet kubeadm kubectl のインストール sudo apt-get update && sudo apt-get install -y apt-transport-https curl curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add - cat <<EOF | sudo tee /etc/apt/sources.list.d/kubernetes.list deb https://apt.kubernetes.io/ kubernetes-xenial main EOF sudo apt-get update sudo apt-get install -y kubelet kubeadm kubectl sudo apt-mark hold kubelet kubeadm kubectl kubeadmを利用したクラスターの作成とCalicoのインストール K8sのクラスター作成のドキュメントと，Calicoのドキュメントの両方を参照しながら進めます． kubeadmはもうインストールされているので，あとは コントロールプレーンノードの初期化 ワーカーノードの追加 の手順を踏めばよいです．いずれも実行するコマンド自体は多くありません． コントロールプレーンノードの初期化 kubeadm initコマンドを利用しますが，その際に利用するCNIプラグイン次第でオプション引数をかえる必要があるようです． Calicoのチュートリアルの方を参照すると， sudo kubeadm init --pod-network-cidr=192.168.0.0/16 で初期化をしているので，これに倣ってコントロールプレーンノードの初期化をします． 最後にkubeadm join 192.168.100.81:6443 --token 5b6zo4.cqje07byosk6wjmb --discovery-token-ca-cert-hash sha256:686401e05de6d479482d8a7b5176d6d28c78a783702e849d1d54507317849e6a のようなコマンドが表示されるので，メモしておきましょう．ワーカーノードをクラスターに追加させる際に利用するコマンドです． 無事完了したら，kubectl がroot以外でも利用できるように ~/.kubeディレクトリ以下を作成します． mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config CNIプラグイン（Calico）のインストール Calicoのインストールは，インターネット上で公開されているyamlをコントロールプレーンノードのkubectl createコマンドに渡すだけです． kubectl create -f https://docs.projectcalico.org/manifests/tigera-operator.yaml kubectl create -f https://docs.projectcalico.org/manifests/custom-resources.yaml ワーカーノードの追加 先ほどkubeadm initした際に発行された，kubeadm joinコマンドを各ワーカーノードで実行すれば完了です． 完了したら，コントロールプレーンでkubectl get nodesコマンドを実行して，ワーカーノードの情報を確認しましょう． STATUSの項目がReadyになっていれば，これでKubernetesクラスターの完成です． 下の例は，作成後しばらくしてから再度実行したものなので，AGEがすこし大きくなっています． $ kubectl get nodes NAME STATUS ROLES AGE VERSION hoge0 Ready control-plane,master 7d13h v1.21.2 hoge1 Ready <none> 7d13h v1.21.2 hoge2 Ready <none> 7d13h v1.21.2 hoge3 Ready <none> 5d7h v1.21.3 hoge4 Ready <none> 5d7h v1.21.3 hoge5 Ready <none> 5d7h v1.21.3

結論 指定したDockerコンテナの対話形式bashシェルを起動して、コマンドの入力を受け付ける状態にすること。 「コンテナに入る」コマンドのおさらい docker exec [オプション] CONTAINER COMMAND [ARG...] 実行例 // 起動しているコンテナの確認 > docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS 9f9d9249cb39 mariadb:10.5.11 "docker-entrypoint.s…" 18 minutes ago Up 18 minutes 0.0.0.0:3306->3306/tcp, :::3306->3306/tcp // MariaDBが起動しているコンテナに入る docker exec -i -t 9f9d9249cb39 /bin/bash //コマンドラインが出力されコマンドを入力できるようになる root@9f9d9249cb39:/# mysql -u root -p とか 細かく見ていく docker exec CONTAINER IDを指定したコンテナのデフォルトディレクトリで新たにコマンドを実行します。 上記コマンドでいうとコンテナのデフォルトディレクトリで「/bin/bash」を実行していることになります。 -i 標準入力を受け付けることを示すオプションです。 -iをつけないとキーボードからの入力を受け付けてくれません。 // -iを付けないでdocker execしてみる docker exec -t 9f9 bin/bash //コマンドラインが正常に表示されているが、キーボードを叩いても何も入力されない root@9f9d9249cb39:/# -t 擬似 TTY を割り当てることを示すオプションです。 TTY(TeleTYpeの略とされているそう)とは、標準入出力となっている端末デバイスを示します。 端末デバイスというとハード的なものが連想されますが、ここではターミナルを指します。 -tをつけないとコマンド入力用のターミナルが割り当てられない...のようなイメージでしょうか。 // -tを付けないでdocker execしてみる docker exec -i 9f9 bin/bash //コマンドラインが表示されない /bin/bash 対話形式のbashシェルを起動してコマンドの入力を受け付ける状態にします。 再まとめ 指定したDockerコンテナの対話形式bashシェルを起動して、キーボードからコンテナ内でコマンドを実行できるようにすることを「コンテナに入る」と表現しているということで理解しました。 コマンドラインを起動して指示を出せるようにしているだけで、あまり「入る」って感じじゃないなあと個人的には思いました。 参考