Linux教育を企画、運営、評価する、何通りかの方法を検討する。 1 道具 Linuxを教育するための道具類を３種類検討する。 1.1 Linux PC intelまたはarmのPCを１台教育用に専用に用意する。 性能は、教育に参加する人に応じて、メモリ、HDDを増やしていくものとする。 Linux を教育するのだから、LinuxPCを用意するのは当たり前だと思うかもしれない。 いえ、当たり前なんです。 課題は、じゃ、端末は何にするかかもしれません。 候補としては、LinuxPC、macOS PC, M.S. Windows OS PC, iPad, Android Pad, iPhone, Android phoneの７種類を候補にあげておきます。 Linux PCの利点 Linux PCの欠点 欠点はないような気がします。 あるとすれば、それぞれの端末がLinuxPCだったときに、システムの管理を経験できる人が限られるか、 システムの管理をする時間が限られるということでしょう。 この欠点は、端末もLinuxPCにすれば成り立ちません。 その場合の欠点は、ネットワーク管理が必要になるということかもしれません。 他の場合は、その１台で閉じることもできるため、ネットワークの管理が必要だとは限らないからです。 この欠点は利点にもなります。クライアントとサーバの両方の管理の経験を積むことができるのですから。 1.2 Windows Subsystem for Linux そんなにありえない選択だとは思っていません。 一度Windows10PCに導入して確認しています。 Ubuntuを選べば、本当にUbuntuとして動作しています。 Windows 10 用 Windows Subsystem for Linux のインストール ガイド https://docs.microsoft.com/ja-jp/windows/wsl/install-win10 Windows 10の機材が存在していることを前提とする。 なければ、すぐに買いにいってください。 ノートPCを想定します。できればメモリは16GBがいいです。 そうじゃなきゃだめというわけではありません。 コンパイルするときに、メモリが少ないと、時間がかかりすぎて泣く。 7万円くらいするらしい。 https://kakaku.com/item/K0001328656/ ディスクトップで探しても、kakaku.comではうまく見つからない。 九十九電機で16GBで探しても７万円切るのは１種類しかない。 https://shop.tsukumo.co.jp/goods/4529327911616/ パソコン工房でさがしたら５万円代でもあった。 https://www.pc-koubou.jp/products/detail.php?product_id=818868&pre=bct1872_bnr_int 最初のノートPCはコア４を指定していた。 やっぱり、Windows10PCがすでにある場合いがい、この選択肢はなさそう。 1.3 Raspberry PI Raspbianを想定します。 理由は、Raspbianしか使ったことがないことと、Debian系のOSしかカーネルソースのコンパイルをしたことがないという個人的な経験の制約によります。 自分の博論の実験機器が、サーバ側がDebianで、Mobile IPをコンパイルする際に、カーネルのパッチ当てが必要だったのですが、apt install によるカーネルの導入とpatchあてとビルドが円滑にできました。 対抗試験としては、FreebSDのカーネルもコンパイルしています。 2. 題材 Linuxの醍醐味の一つは、コンパイル・ビルドかもしれない。 2.1 コンパイル・ビルド 2.1.1 コンパイラのコンパイル コンパイラのコンパイルは、一つの山場です。 intelとarmで考えると、セルフコンパイルとクロスコンパイルを検討してみましょう。 2.1.2 カーネルのコンパイル Linux自身のコンパイルも、二番目の山場です。 コンパイラがコンパイルできたからといって、カーネルがコンパイルできないのであれば、 オープンソースとしてのLinuxの価値が半減してしまうかもしれません。 2.1.3 他のアプリのコンパイル Debian系のaptであっても、すべてのアプリのバイナリがあるとは限りません。 アプリのコンパイルも大切です。 2.2 docker 次はgithubにするかdockerにするか悩みました。 dockerにした理由は、dockerの方が使い慣れているからだけです。 macOS, Windows OSの端末の場合は、それそれのdocker用アプリの導入が必要になります。 2.2.1 docker上でのコンパイラのコンパイル 2.2.2 docker 上でのカーネルのコンパイル 2.2.3 docker上でのアプリのコンパイル 2.3 git 2.3.1 github/gitlab/bitbacketの利用 多くのオープンソースの活動は、公開のGithubなどにソースを置いて運営しています。 これらを利用することから始めましょう。 すでに、コンパイル、dockerの利用で使っているかもしれません。 意識して再整理するだけでも結構です。 2.3.2 gitlabの導入 セルフマネージドGitLabをインストール https://www.gitlab.jp/install/ 公開のサーバや、プライベートのサーバでも、サーバの利用に制限がある場合は、gitlabを導入しましょう。 2.3.3 git 系の　他の作業 未定 2.4. 文書分類 2.4.1 Web/html Web, Browserによる処理は、いろいろな作業の過程で必要になることがあります。 資料の整理や、発表などです。 2.4.2 markdown/wiki Web, browserを使っても、使わなくてもmarkdownは必須だと思います。 2.4.3 LaTeX え、jsonじゃないのとか、XMLはどうしたと思われるかもしれません。 それらはデータ形式の方に追いやっておきます。 2.5 データ形式 s.5.1 json 2.5.2 XML 2.5.3 その他のデータ形式 2.6. プログラミング言語 2.6.1 C言語 C言語規格のソースコード断片のコンパイルと、MISRA C, CERT Cなどのコーディング標準のソースコードのコンパイルは行います。 2.6.2 C++ C++規格のソースコード断片のコンパイルと、MISRA C++, CERT C++, AUTOSAR C++などのコーディング標準のソースコードのコンパイルは行います。 2.6.3 python JAVAじゃないのかとか、C#はどうしたとか、javascritpはって思うでしょう。 ごめんなさい。今、興味がまだ湧いていません。 JAVAについては、興味が冷めたといった方がいいかもしれません。 2.7. 試験 2.7.1 単体試験 2.7.2 POSIX Test suite 2.8.3 その他の試験 3 人数 3.1 4人未満 演習系で、一人の講師で、手が届くのは４人くらいかもしれません。 人の能力によります。絶対にそうだとはいえません。 3.2 16人未満 ４人以上になったら、3人に一人、グループリーダを決めてもらいます。 そうすると、15人なら５グループできることになります。 ５人のリーダに話を伝えたり、５人のリーダから報告を聞けばよいような仕組みを作ります。 この人数の課題の一つは、機材管理です。経験的に8台以上の機材があると、 どれか一台はなにかしてくれちゃうことがあります。 故障の場合もあります。OSのインストールのし直しが必要なこともあります。 呼びの機材が１台以上必要です。 3.3 64人未満 ３人づつのグループが最大２１あります。７グループごとにグループリーダを決めてもらいます。 基本的に３人のグループリーダが、６人のリーダと、自分のグループのメンバに対応してくれます。 この人数になると、最大の課題は機材管理です。 グループリーダごとに２台の呼びの機材があ必要で、合計６台の予備を用意します。 4. 進捗管理 4.1 Github/Gitlab/Bitbucket またはWeb 4.2 進捗管理ツールのカスタマイズ 4.3 統計分析ツールの作成 場合によっては機械学習も。 5 日程計画 案1 1日目。 Windows PCの場合は、WSLを導入して、Ubuntuを起動するまでに数時間かかる。 PCにLinuxを導入する場合には、１時間くらいで済みそう。 Raspberry PIはRaspbianのSDカードがあること前提だけど、 ない場合には、PCでSDにダウンロードする作業が慣れないと、１時間以上かかるかも。 初日にはコンパイラをコンパイルしたい。 場合によってはクロスコンパイラでもいい。 Raspberry PIで作業をする場合に、Raspberry PI でコンパイルするよりも、 もっと高速でメモリのたくさんあるPCでコンパイルした方がいいかもしれないし。 Dockerをどっかーらどうやって使えばいいんでしょう。TOPPERS/FMP on RaspberryPi with Macintosh編 ５つの関門。「名古屋のIoTは名古屋のOSで」。docker (37) https://qiita.com/kaizen_nagoya/items/9c46c6da8ceb64d2d7af 仮説・検証（175）コンパイラを書くのは難しいか LLVMソースコードのコンパイルをしようと思ってハマった罠とそこから脱出するための努力 2 日目　C言語標準 [C][C++]の国際規格案の例題をコンパイルするときの課題７つ。 5日目　MISRA C, CERT C MISRA C まとめ #include docker(200) Misra Example Suite at docker コンパイル完了までの道のり 15日目。 今日から、Ethernet/TCP/IP Linuxを触っていて、TCP/IPを操れないと意味がないかも。 まず、wiresharkの導入。 Wireshark 導入、記録、分析。無線網（Wi-Fi）空中線(antenna)(64) https://qiita.com/kaizen_nagoya/items/d1d452d5f3eadd420d6e ban # apt install wireshark 「かんたんな疎通確認」をwiresharkで https://qiita.com/kaizen_nagoya/items/93acbe7ea1a43ffd56e4

上記の設定が出来ていることが前提となります。 ■traefik.ymlの変更 /tmp/traefik.yml # 変更前 certificatesResolvers: default: acme: email: system@test.local storage: acme.json httpChallenge: entryPoint: web /tmp/traefik.yml # 変更後 certificatesResolvers: default: acme: email: system@test.local storage: acme.json tlsChallenge: {} # ステージングでの確認はURLが異なります caServer: https://acme-v02.api.letsencrypt.org/directory httpChallenge: entryPoint: web ■docker-compose-app.yml docker-compose-app.yml # 変更前 # 443設定 - traefik.http.routers.test-app-test-secure.rule=Host(`apptest.local`)) - traefik.http.routers.test-app-test-secure.entrypoints=secure - traefik.http.routers.test-app-test-secure.tls=true - traefik.http.routers.test-app-test-secure.service=test-app-test-secure-service - traefik.http.services.test-app-test-secure-service.loadbalancer.server.port=80 docker-compose-app.yml # 変更後 # 443設定 - traefik.http.routers.test-app-test-secure.rule=Host(`apptest.local`)) - traefik.http.routers.test-app-test-secure.entrypoints=secure - traefik.http.routers.test-app-test-secure.tls=true # certresolverを追加 - traefik.http.routers.test-app-test-secure.tls.certresolver=default - traefik.http.routers.test-app-test-secure.service=test-app-test-secure-service - traefik.http.services.test-app-test-secure-service.loadbalancer.server.port=80 ■SSL証明書対応について 上記の２ファイルを少し変更するだけで対応できます。 設定変更後、traefikコンテナの再起動が必要になります。

テーブル定義書をコンテナで作成します ※コンテナからDBに接続が出来る必要があります ■Dockerfile FROM httpd:alpine # bashを使用する場合はbashをインストールする必要があります # libxslt は xsltproc を使用するのに必要です # tzdata は日本時間に変更する場合 RUN apk update \ && apk add \ bash \ mysql-client \ libxslt \ tzdata \ && cp -f /usr/share/zoneinfo/Asia/Tokyo /etc/localtime \ && apk del tzdata ■定義書を作成(shell) # スキーマ「test_schema 」の定義書を作成します FILE_INDEX=/usr/local/apache2/htdocs/index.html FILE_DUMP=/tmp/mysqldump.xml FILE_TEMPLATE=/tmp/style.xslt DB_HOST=localhost DB_NAME=test_schema DB_USER=dbuser DB_PWD=test MYSQL_PWD=${DB_PWD} mysqldump -h ${DB_HOST}-u ${DB_USER} --no-data --xml ${DB_NAME} > ${FILE_DUMP} \ && xsltproc -o ${FILE_INDEX} ${FILE_TEMPLATE} ${FILE_DUMP}

初めに LambdaアプリケーションをSAMで開発するにあたりコンテナでデプロイを初めて取り扱うにあたり色々試行していたのですが、 せっかくコンテナで環境をそのまま持ってけるんだからローカル環境も同じコンテナで処理したい！ でもDockerfileの多重管理はしたくない！となっていい方法がないかと模索していたところ 割と良さげな方法がありましたので備忘録がてらまとめます。 AWSのサポートに問い合わせてみたら記事執筆時点(2021/08/27)では まだ公式のドキュメントが追いついてなく記載がなく追記予定らしいです。 こんなことしなくてももっと簡単にできるよっていうのがあったらご教示いただければと思います。 何がしたかったか 今回はAWS公式で提供されているpython3.8のイメージをベースとします。 大元のDockerfileはドキュメントに記載の通り以下で ENTRYPOINT ["/lambda-entrypoint.sh"] が実装されており、これに対して CMD で引数を渡すような作りをすることで対象のスクリプトを実行できます。 https://github.com/aws/aws-lambda-base-images/blob/python3.8/Dockerfile.python3.8 ただしこのコンテナをローカル開発で利用するにあたり以下の点が不満でした sam経由で実行する場合sam build と sam local invoke が必要 せっかくのスクリプト言語なのにいちいちビルドが必要で確認がめんどくさい build問題はsamを経由せずに 　ボリュームをマウントdockerコマンド経由で実行してやれば解決はするが次項の問題がある コンテナは起動するとスクリプトの実行が終わるのでコンテナを立ち上げっぱなしにできない ちょっと確認のためにコンテナ内で作業したいとかがやりづらい なのでローカル用にはENTRYPOINT ["tail", "-f"]を実装したDockerfileを利用し、 通常時は内部でpythonコマンド経由で実行しある程度整理できたところで、 sam経由で実行のようなことを考えていました。 ただしこのためにDockerfileを複数作って管理というのは共通部分を多重に管理しないといけないため回避したい問題でした。 解決方法 Dockerのマルチステージビルドを使うことで解決できました。 今回調べるまで知らなかったのですがdocker build の--targetオプションで指定したステージを最終成果物としてできることを知りました。 ただdocker build --target=xxxと同じ挙動をするものがSAMに見当たらないという点でつまづきました。 sam buildのドキュメントにもなくSAMのアプリケーションビルドのページにもなかったのでAWSに問い合わせしてみたのですが、 ドキュメントが追いついていないだけでSAM CLI 1.12.0で実装されていたようです。 (SAM側のテンプレートファイルのDockerBuildTargetで利用するステージの指定が可能) https://github.com/aws/aws-sam-cli/issues/2578 各種実装 ファイルの配置 testフォルダとか一部省略してます。 docker-compose.ymlが増えている以外はsam initで作られるのと同じです。 . ├── src │ ├── Dockerfile │ ├── docker-compose.yml │ ├── __init__.py │ ├── requirements.txt │ └── app.py └── template.yaml Dockerfileの実装 最初にデプロイ用のprodイメージを作り、 その後にそこからローカル開発用に一部を書き換えたdevイメージを作成します。 Dockerfile FROM public.ecr.aws/lambda/python:3.8 as prod #ソースコード類をコピー COPY ./* ./ RUN python3.8 -m pip install -r requirements.txt CMD ["app.lambda_handler"] FROM prod AS dev ENTRYPOINT [ "tail", "-f"] docker-compose.yml 個人的にはdocker-compose経由の起動が楽なのでdocker-compose.ymlも作っておきます。 このdocker-compose.ymlはローカルの開発専用でSAMでデプロイする場合は後述のSAMテンプレート側が読まれます。 target: devを指定することでdocker-compose経由で起動する場合はdev側のイメージを利用します。 docker-compose.yml version: "3" services: app: build: context: . dockerfile: Dockerfile target: dev volumes: - .:/var/task template.yml SAM側のコンテナの設定系はMetadataで設定します(詳しくはSAMのアプリケーションビルドを参照) このMetadataにDockerBuildTargetで対象のステージを指定することができるようです。 (2021/08/27時点で記載がなかったのはこのパラメータ) なおこのパラメータをなしで実行すると最終のdevまで実行されたものが利用されました。 template.ymlは以下のような形で実装します(一部省略) template.yml AWSTemplateFormatVersion: '2010-09-09' Transform: AWS::Serverless-2016-10-31 ... Resources: CreateMntFolder: Type: AWS::Serverless::Function Properties: PackageType: Image ... Metadata: Dockerfile: Dockerfile DockerContext: ./src DockerTag: python3.8-v1 DockerBuildTarget: prod こうすることでDockerfileを多重管理する必要もなくなり、 ちょっと確認したい時はdocker-compose up -d経由でコンテナを立ち上げ、 docker-compose exec app bashで内部に入って実行もできますし、 sam buildからのsam local invokeやsam local start-api等の各種ローカル実行系のコマンドでの確認もできます。 終わりに マルチステージビルドはDocker公式チュートリアルちょっと読む限りは中間成果物があるような環境のために 使い捨ての作業イメージが作れるくらいのイメージでした。 実際はそうではなくSAMに限らずこれまで環境ごとに複数Dockerfileを作っていたのが、 一つのファイルで共通の部分の中間イメージを作りそこから個別実装ということができたり、 今回みたいに用途によって途中のステージのものを利用することもできたりと 少し視野を広く持っていればいろいろなことができそうです。 一つのDockerfileにアプリとDBのイメージを両方記載してdocker-compose.ymlでtargetパラメータをうまく指定することで Dockerfileを一つにまとめられそうなんですがどうなんでしょうか。 同じこと考えている人はいそうなのでこの辺りはまたチュートリアルとかフォーラムとか色々みてみようかと思います。

はじめに 近年、Dockerで環境構築をする機会が増えていますが、駆け出しエンジニアからしたら何が何だか分からず発狂したくなりますよね。 そういった過去を抱えている自分がDockerを最低限使えるようになれたら良いなと願いを込めて記事を書きます。 Dockerとは Dockerとは、内部でコンテナ技術を利用しており、様々な環境でアプリケーション実行環境を構築・運用するためのオープンソースのプラットフォームです。 Dockerでは、必要なライブラリ群や。アプリケーションの実行に必要な全てのファイル・ディレクトリ群、インフラ環境などをコンテナとして１つにまとめます。 Dockerを利用すると、別環境でエラーが発生するなどのリスクを減らすことができます。 コンテナとは コンテナとは、ホストOS上に論理的な区画を作成し、アプリケーションを動作させるのに必要なライブラリなどを１つにまとめることが出来ます。コンテナはオーバーヘッドが少ないため。軽量で高速に動作します。 また、アプリケーションの実行に必要なものをまとめることができるので、複数のコンテナを組み合わせて１つのアプリケーションを構成するマイクロサービス型のアプリケーションと親和性が高いです。 大まかな機能 Dockerには大きく分けて、次の３つの機能があります。 Dockerイメージを作る機能（Build） Dockerイメージを共有する機能（Ship） Dockerコンテナを動かす機能（Run） 以下でこの３つの基本機能を説明していきます。 Build Dockerfileというファイルに書かれた内容をもとにDockerイメージを作成します。 Dockerイメージは、Dockerのコマンドを使って手動で作ることも、Dockerfileという設定ファイルを作ってそれをもとに自動でイメージを作ることもできますが、Dockerfileを使って管理することが望ましいです。 また、Dockerイメージは積み重ねて利用できます。Dockerでは構成に変更があった部分を差分（イメージレイヤー）として管理します。 Ship DockerのイメージはDockerレジストリ(Docker Hubなど)で共有できます。 公式のDockerレジストリであるDocker HubではUbuntuやMySQLなどよく使うもののベースとなるDockerイメージが配布されています。これらのベースイメージをカスタマイズし、イメージを積み重ねて独自のDockerイメージを作っていきます。 Run Dockerは、コンテナ単位でサーバ機能を動かします。このコンテナのもとになるのが、Dockerイメージになります。また、Dockerイメージから複数のコンテナを起動することもできます。コンテナの起動・停止・破棄は、Dockerのコマンドを使います。 基本的な使い方 以下、Dockerを利用する際の基本的な操作を記載しています。 Dockerイメージのダウンロード Dockerイメージを取得するには、docker image pullコマンドを使用します。 # docker image pull [オプション] イメージ名[:タグ名] $ docker image pull centos:7 #=> CentOSのバージョン７をダウンロード Dockerイメージの一覧取得 取得したDockerイメージの一覧表示は、docker image lsコマンドを使用します。 # docker image ls [オプション] [レポジトリ名] $ docker image ls REPOSITORY TAG IMAGE ID CREATED SIZE イメージの名前 イメージタグ名 イメージID 作成日 イメージのサイズ オプション一覧 オプション 内容 -all, -a すべてのイメージを表示 --digests ダイジェストを表示するかどうか --no-trunc 結果をすべて表示 --quiet, -q DockerイメージIDのみ表示 Dockerイメージの削除 作成したDockerイメージはdocker image rmコマンドで削除できます。 # docker image rm [オプション] イメージ名(or ID) [イメージ名(or ID)] $ docker image rm samle_image オプション一覧 オプション 内容 --force, -f 強制的にイメージを削除 --no-prun 中間イメージを削除しない コンテナ生成・起動 コンテナの生成・起動には、docker container runコマンドを使用します。 # docker container run [オプション] イメージ名[:タグ名] [引数] $ docker container run -p 8080:80 nginx #=> ホストの8080ポートにアクセスすると、コンテナ上で動作しているNginx（80番ポート）のサービスにアクセス オプション一覧 オプション 内容 --attach, -a 標準入力/出力/エラー出力にアタッチ --detach, -d コンテナを生成し、バックグラウンドで実行 --name [コンテナ名] コンテナ名を設定 コンテナ停止 起動しているコンテナを停止する時は、docker container stopコマンドを使用します。 # docker container stop [オプション] コンテナ名(or ID) [コンテナ名(or ID)] $ docker container stop sample_container コンテナ削除 停止しているコンテナを削除するときは、docker container rmコマンドを使用します。 $ docker container rm [オプション] コンテナ名(or ID) [コンテナ名(or ID)] $ docker container rm sample_container オプション一覧 オプション 内容 --force, -f 起動中のコンテナを強制的に削除 --volumes, -v 割り当てたボリュームを削除す Dockerfileを利用する Dockerfileとは、Docker上で動作させるコンテナの構成情報を記述するファイルのことです。 具体的には、以下のようなものを記載しておきます。 ベースになるDockerイメージ Dockerコンテナ内で行った操作（コマンド） 環境変数などの設定 Dockerコンテナ内で動作させておくデーモン実行 記載例 # CentOSのベースイメージを設定 FROM centos:7 # build時に指定したコマンドを実行させる RUN echo "now building..." RUN yum -y install httpd RUN sed -i '/#ServerName/a ServerName www.example.com:80' /etc/httpd/conf/httpd.conf # index.htmlをコンテナにコピー ADD ./index.html /var/www/html/ # 80番ポートをエクスポート EXPOSE 80 # イメージ作成後、指定したコマンドを実行する CMD ["/usr/sbin/httpd", "-D", "FOREGROUND"] 主な命令文 命令 内容 FROM ベースイメージの設定 RUN build時にコンテナ内で実行 CMD 完成したイメージからコンテナを作成するときに実行 LABEL ラベルを設定 EXPOSE ポートのエクスポート ENV 環境変数 ADD ファイル/ディレクトリをコンテナにコピー COPY ファイルのコピー ENTRYPOINT コンテナの実行コマンド VOLUME ボリュームのマウント USER ユーザーの指定 WORKDIR 作業ディレクトリの変更 ARG Dockerfile内の変数 SHELL デフォルトシェルの設定 docker-composeを利用する 一般的にDockerを利用する際は、複数のDockerコンテナが協調して動作します。Docker Composeを利用することで、複数のコンテナをまとめて管理する事が出来ます。 docker-compose.ymlというファイルにコンテナの構成情報を定義し、同一のホスト上の複数のコンテナを一括管理できます。 記載例 docker-compose.yml version: '3' # バージョンを指定 services: # 管理したいコンテナのサービス db: # DBサーバー用のコンテナの設定 image: mysql:5.7 # コンテナで使用するイメージ名を記載 environment: # 環境変数を設定 MYSQL_ROOT_PASSWORD: password # 任意のパスワードを設定 MYSQL_DATABASE: sample_db # 任意のデータベース名を設定 ports: - "3306:3306" # ホストの3306ポートとコンテナの3306ポートを接続 web: # APPサーバー用のコンテナの設定 build: . # docker-compose.ymlと同じ階層のDockerfileを使ってイメージをbuild command: bundle exec rails s -p 3000 -b '0.0.0.0' # コンテナ立ち上げ時に起動するコマンド volumes: # ボリュームを設定 - .:/sample_app # 作業ディレクトリをコンテナ内の/sample_appにマウント ports: # ポートを設定 - "3000:3000" # ホストの3000ポートとコンテナの3000ポートを接続 links: - db # dbコンテナと接続 終わりに こんな簡単なことかよっっ！！と思うかもしれないけど、意外と基礎を固めることは大事なのでド忘れした時などに見返してね！

別の記事に投稿している内容に関連して、Docker Runのオプションについて少し調べてみました。 参考ページ コンテナの作成・実行 SonerQubeのコンテナ作成で↓こんなコマンドを実行してます。 docker run -itd --name sonar -p 9000:9000 sonarqube runについて まずはrunについて、runはcreate＋startコマンドを合わせたコマンドになっていて。 コマンド 　　　　　 概要 run create＋start create コンテナ作成のみ行われる start 作成済みのコンテナを開始する オプション 上記で使用している-itdは下にある-i,-t,-dを合わせたオプション 　　コマンド 　　　　　 概要 -i, --interative=false コンテナの標準入力を開く -t, --tty=false tty(端末デバイス)を使う -d, --detach=false バックグラウンドで実行する --name コンテナ名 -p {ホストのポート}:{コンテナのポート}

背景 Laravel等のPHPウェブシステム開発ではDocker for Macが遅い問題があり、Vagrant上に立てたDockerコンテナで開発を行うことが多い。 その際に最近リリースされたDocker compose CLIを使いたい。 そこそこ詰まった&&ネット上にあまり情報がなかったのでメモ。 環境 macOS Catalina Virtual box 6.1 Vagrant 2.2.14 Ubuntu 20.04 (Vagrant上に立てるVM) Docker 20.10.8 実装 Vagrantファイルにdockerと docker composeコマンドをインストールするスクリプトを追加。 Vagrantfile # -*- mode: ruby -*- # vi: set ft=ruby : Vagrant.configure("2") do |config| # Sync Directory config.vm.synced_folder "/path/to/host/sync/dir", "/home/vagrant/workspace", create:"true", mount_options: ['dmode=777','fmode=777'] # Mapping ports config.vm.network "forwarded_port", guest: 8000, host: 8000 config.vm.network "forwarded_port", guest: 3306, host: 3306 config.vm.network "forwarded_port", guest: 8080, host: 8080 config.vm.network "forwarded_port", guest: 4572, host: 4572 config.vm.network "private_network", ip: "192.168.33.10" # Start ssh agent config.vm.provision "shell", run: "always", inline: <<-SHELL echo 'eval `ssh-agent`' > /home/vagrant/.bash_profile SHELL # setup config.vm.provision "shell", inline: <<-SHELL apt-get -y upgrade apt-get -y update # docker, docker compose curl -fsSL https://get.docker.com -o get-docker.sh sh get-docker.sh curl -fsSL https://github.com/docker/compose-cli/releases/download/v2.0.0-beta.3/docker-compose-linux-amd64 -o .docker/cli-plugins/docker-compose --create-dirs chmod 755 .docker/cli-plugins/docker-compose chown -R vagrant:vagrant .docker usermod -aG docker vagrant gpasswd -a vagrant docker systemctl enable --now docker systemctl restart docker echo 'eval `ssh-agent`' > /home/vagrant/.bash_profile SHELL config.vm.box = "bento/ubuntu-20.04" end 解説 Shell Scriptからdockerコマンドをインストール ※本番環境ではインストールスクリプトの使用は非推奨 1 curl -fsSL https://get.docker.com -o get-docker.sh sh get-docker.sh Docker compose CLIをインストール ※現状インストールスクリプトではインストールできない模様 2 curl -fsSL https://github.com/docker/compose-cli/releases/download/v2.0.0-beta.3/docker-compose-linux-amd64 -o .docker/cli-plugins/docker-compose --create-dirs chmod 755 .docker/cli-plugins/docker-compose 権限の調整と docker, docker compose コマンドをvagrantユーザーでも使用できるようにする。 chmod 755 .docker/cli-plugins/docker-compose chown -R vagrant:vagrant .docker usermod -aG docker vagrant gpasswd -a vagrant docker 結言 記事へのご指摘歓迎 補足 VagrantファイルはGithubにおいてあります。 https://docs.docker.com/engine/install/ubuntu/#install-using-the-convenience-script ↩ https://github.com/docker/compose-cli/issues/1781 ↩

SonerQubeで何かできるか、どこまでの精度なのかを調査する前段階として導入までの手順をまとめます。 参考にした記事 https://qiita.com/takao-takass/items/5d54768ad0d315d3dad4 Dockerのコンテナを使えば楽々導入できました。 詰まったのはポート設定くらいでした。 実施環境 Windows10 Pro Windows10 へDockerインストールについては コチラ を参照。 SonerQubeコンテナ作成 コマンドプロンプトを開いて、dockerSonerQubeページ に載ってるコマンドを実行します。 docker pull sonarqube Docker Run SonerQubeのポートは9000なので、ポートフォワーディングで9000に接続します。 （特に設定しないと、任意のポートが割り振られたので、要検証・・・） docker run -itd --name sonar -p 9000:9000 sonarqube SonerQubeのページにアクセスする ブラウザを起動して下記にアクセスします。 http://localhost:9000 もしくは、 http://{hostネーム or IPアドレス}:9000 わー！開けました！ ログインやテストスキャンは、また別途まとめます。

#はじめに メモをとっているものの、実際には公式マニュアルを読めば大丈夫である。リンクは下。 https://docs.docker.jp/docker-for-windows/install-windows-home.html #WSLの有効化 ・Windows Subsystem for Linux　つまりwindowsでLinuxを利用すること ・仮想化も有効にする →「windowsの機能の有効化または無効化」で以下の２つにチェック ① Linux用windowssサブシステム ② 仮想マシン　プラットフォーム #WSL2に更新する こちらのサイトのパッケージをDL&実行＝手順４（WSL2更新パッケージ） https://docs.microsoft.com/ja-jp/windows/wsl/install-win10#step-4---download-the-linux-kernel-update-package 以下のコマンドを実行 // PowerShell wsl --set-default-version 2 #Ubuntu20.04をインストール ・MicroSoft Storeより入手する。 ・CentOSは対応していない模様。githubのリポジトリ存在はあるが、公式マニュアルはない。 ・Ubuntuを起動し、最初のユーザーを生成する。 ・aptコマンドを更新 $ sudo apt update && sudo apt upgrade #DockerHub for Windowsをインストール DLサイト https://hub.docker.com/?overlay=onboarding 参考URL 公式 ・Homeにインストールする　https://docs.docker.jp/docker-for-windows/install-windows-home.html ・WSL2について　https://docs.docker.jp/docker-for-windows/wsl.html ・WSL2更新パッケージ https://docs.microsoft.com/ja-jp/windows/wsl/install-win10#step-4---download-the-linux-kernel-update-package ・Ubuntuの初期設定　https://docs.microsoft.com/ja-jp/windows/wsl/user-support 非公式 ・https://qiita.com/idani/items/fb7681d79eeb48c05144 ・https://qiita.com/teckback/items/c048faef648da6c83058 ☆CentOSをインストールする場合の方法はこちら（非公式） https://www.geekfeed.co.jp/geekblog/install_centos8_on_wsl2_for_free

人生初投稿！ 初めてQiitaに投稿をします．もし間違い等あれば，ご指摘していただけると幸いです． 自動アノテーション(auto annotation)とは? あらかじめ用意していたデータベースから，システムが画像におけるメタデータを自動で付与してくれる機能のことを指します．CVATではそれをAIで実現しており，yoloといったモデルを使用して，自動で画像や動画のアノテーションを行なってくれます． なお、2021年8月時点での最新Releaseバージョン1.5を使用しています．ネット上の日本語での記事を検索したところ，バージョン1.2に関しての記事しかありませんでした．1.5と1.2ではCVATの起動方法が大幅に変更されているので，最新版を使用されたい方はこちらの記事をご参考ください. 記事の内容 CVATの起動と使い方 CVATの自動アノテーションを試す オンライン版お試しCVAT 環境 MacBook Pro Core i7 VS Code Docker version 20.10.8 既にdockerがPCにインストールされていることを前提としています．もしまだの方はDocker Desktopをインストールしてください． Dockerを使用するので、WindowsでもLinuxでも同様の手順でCVATを使用することができます. 後述しますが，何故かWindowsでは自動アノテーションがうまく起動しませんでした... GitHubのレポジトリをクローンする git clone https://github.com/openvinotoolkit/cvat/tree/release-1.5.0 GitHub Desktopを使用する場合は 「current repository ▼」 ? 「Add ▼」 ? 「Clone Repository」 ? 「URL」タブでhttps://github.com/openvinotoolkit/cvat/tree/release-1.5.0を入力してcloneボタンをクリックしてください． CVATの初期設定をする vs codeでdocker-compose.ymlを以下のように変更してください．アノテーションしたい画像を入れたディレクトリ(フォルダ)をあらかじめ設定しておくことで作業がしやすくなるので．'/Users/○×□'を自身の環境に合わせて設定してください． Mac(おそらくLinuxも) services: ... cvat: ... volumes: - cvat_data:/home/django/data - cvat_keys:/home/django/keys - cvat_logs:/home/django/logs - cvat_share:/home/django/share #追加 ... volumes: ... cvat_share: driver_opts: type: none device: '/Users/○×□' # マウントしたいディレクトリ o: bind Windows services: ... cvat: ... volumes: - cvat_data:/home/django/data - cvat_keys:/home/django/keys - cvat_logs:/home/django/logs - C:\Users\○×□:/home/django/share #マウントしたいフォルダ CVATの立ち上げ フォルダを指定した後，CVATを起動します． docker-compose -f docker-compose.yml -f components/serverless/docker-compose.serverless.yml up -d コンテナがすべて立ち上がれば成功です． CVATのセットアップ 以下のコードを入力してください．ここではDjangoのスーパユーザの作成を行なっています．email addressの登録はreturn(enter)を押してパスしてもらって大丈夫です． 入力したユーザ名とパスワードは後で使用するので，覚えておいてください． docker exec -it cvat bash -ic 'python3 ~/manage.py createsuperuser' これでセットアップは完了です． CVATを触ってみる タスク作成 http://localhost:8080/ にアクセスしてください． 以下のような画面が出てくるので，先ほど設定したユーザネームとパスワードでログインしてください． ログインした後このようなトップページが出てくるので， + Create new taskをクリックしてタスクを作成します． NameやLabelsを設定していきます．Labelの色はしっかりと設定しておいた方が後のアノテーションがしやすくなります． また，アノテーションに使用する画像は先ほどマウントしたフォルダ(ディレクトリ)から取得するので，Connected file shareをクリックし，使用画像に☑を入れてください． 全ての項目を設定し終えた後，submitボタンをクリックします． このポップアップが右側に出現すると，タスク作成は完了です． アノテーションをしてみる では一度アノテーションを手動でしてみましょう． Jobsのjob#1をクリックしてください． この□にカーソルを持っていくと，下の画像のようなポップアップがでます． ここでShapeをクリックすると，アノテーションモードになります．囲んでみると，以下のようにアノテーションをすることができます． ですが，手動で全画像をアノテーションをするのはきつく，CVATの意味がありません！ では，本題の自動アノテーションを設定してみましょう． CVATの自動アノテーション機能をオンにする yolo-v3を使用して自動アノテーションを使用しました． ローカルにnuclioを導入します． https://github.com/nuclio/nuclio/releases/tag/1.5.16からPCの環境に応じてダウンロードしてください． なお，nuclioのバージョンは docker-compose.serverless.ymlのnuclioのバージョンと合わせてください． nuctl-1.5.16-darwin-amd64 #Mac nuctl-1.5.16-linux-amd64 #Windows nuctl-1.5.16-windows-amd64 #Linux Mac (Linux) sudo chmod +x nuctl-1.5.16-linux-amd64 sudo ln -sf $(pwd)/nuctl-1.5.16-linux-amd64 /usr/local/bin/nuctl Windows 色々試してみましたが，上手くいきませんでした．Windowsの方はWSL2でDockerを動かしており，Hyper-Vの方では試していません．GitHubのissueを探してみると，同様の問題が発生している方がいらっしゃいました... ここでcvatというプロジェクトを作ります．(cvatという名前以外はCVATでは使用できませんでした) nuctl create project cvat もし上手くいかない場合は，http://localhost:8070/ にアクセスしてGUIでプロジェクトを作成してください． ここでは，yolo-v3モデルをぶちこみます． nuctl deploy --project-name cvat \ --path serverless/openvino/omz/public/yolo-v3-tf/nuclio \ --volume $(pwd)/serverless/common:/opt/nuclio/common \ --platform local 私の場合ここでエラーが発生し，コンテナの立ち上げができませんでした．原因を探ってみると，コンテナが0番ポートに割り当てられていたようなので，serverless/openvino/omz/public/yolo-v3-tf/nuclio/function.yamlファイルにポート番号を追加しました．ポート番号は任意の番号で大丈夫(?)だと思います． (どうやらこれはバグらしく，nuclioの方では既に修正済みのようですが，CVATが旧バージョンを使用している事が起因して発生しているようです．早く修正バージョンがリリースされるといいですね...) triggers: myHttpTrigger: maxWorkers: 2 kind: 'http' workerAvailabilityTimeoutMilliseconds: 10000 attributes: port: 55952 #追加 maxRequestBodySize: 33554432 # 32MB すると，上手くいきました． CVATを立ち上げ，リロードをしてみると Projects Tasks の横に Models が出現しました．それをクリックしてみると，以下のように YOLO v3 が表示されています． では，先程のアノテーション画面に戻ります．左のバーをみると，AI Toolsが追加されていることがわかります． DetectorsからYOLO v3を選択してください． 例ではマリトッツォを自動アノテーションで検出してみます．マリトッツォはどちらかというとケーキのような見た目なので，yoloのケーキ検出機能を使って，マリトッツォのアノテーションを行ってみます． アノテーションを行うと，見事マリトッツォがアノテーションされていました！ この自動アノテーションは一枚ずつ行うこともできますが，まとめてアノテーションすることもできます．Tasksを開いて，Actionsボタンをクリック→Automatic annotationをクリックするとそのタスク内の全画像の自動アノテーションが始まります． オンライン版 CVATを一度お試しで使ってみたい，という方向けにオンラインdemo版が用意されています．環境構築が出来なかった！ という方はこちらでCVATを体験できます． 最後に CVATの自動アノテーションはとても楽ですね．物体検出の他にセグメンテーションも行うことができます．今までは全て手動でしなければいけなかったのですが，CVATで大幅に時間短縮ができます．特にセグメンテーションは何回もマウスをポチポチすることになるので，この手間が削減されるのはとても助かります． この記事が面白いなと思ったらLGTMよろしくお願いします！ 今後も記事を書いていきますので，そちらの方も見て頂ければ幸いです? 参照 CVAT CVAT Docs

概要 Docker環境を作ることで大体どの環境でもDocker化したシステムが動作できるのはとても魅力的だと思います。 QAエンジニアをやっているとテスターさんにSelenium IDEを導入してもらって、テスト要件やテストケースをもとにテスト操作することで自動的にでテストコードができるので便利です。 このときできたテストコードは、調整が必要なのでそのままE2Eテストとして扱うのは難しいですが、全部使えないとしても一部のテスト（認証関連や全ページ遷移の確認など）はそのまま運用できるぐらい効率の良いやり方だと思います。 ですが、できたテストコードをテスターさんがSelenium IEDを起動してテストの実行を手動作業することになるのでちょっと非効率になります。 　　　 そこで今回は、上記のイメージズのようにSeleniumを実行できる環境をDockerで作って、定期実行させることでE2Eテスト環境がコスパ良くできると考え、その方法をまとめます。 また、Dockerじゃなくても他のやり方として、JenkinsにSeleniumを実行するような環境をあるのであればそっちを活用してもいいと思います。 ゴール 今回は、タイトルの通り「Selenium IDEで作ったテストコードをDocker化したSeleniumでE2Eテスト」できる環境を作れるところまでとなります。 環境 次の環境がセットアップできたらどのPCでも大丈夫です。 あとは、お好みでエディタが入っていると作業しやすいです。 Docker Docker Compose Selenium IDE Selenium IDE 先にテストコードを作っておきましょう。 セットアップや途中でDockerが動かない状況が起きたとしても、最悪Selenium IDEでE2Eテストできるので。 例として今回は、Googleにアクセスして「qiita」を検索して、トップにヒットしてqiita.comにアクセスしてマイページまで正常にアクセスできるのか確認するテストを作ってみました。 Selenium IDEの入門的な話は割愛するので、他の記事を参考にしてください。 まずは、Selenium IDEのプロジェクトを作っていきます。 作成すると早速レコーディングが始まるのでテストしたい操作を登録していきます。 登録が終わったらSelenium IDEのアイコンからエディタを開いて、登録したテストを保存します。 保存したテストを右クリックからテストコードをダウンロードして、最後にプロジェクトを保存（Ctr＋s）すればSelenium IDEの作業は一旦終わりです。 Docker 次にSeleniumのDocker環境を作っていきます。 Dockerに関しても入門的な話は割愛するので、他の記事を参考にしてください。 /srcに先ほどダウンロードしたテストコード（test_202108qiitauserpagecheck.py）を配置します。 Dockerfile # https://q-three.com/archives/1031 # ベースイメージはpython:3.7 FROM python:3.7 USER root # 環境変数設定 ENV PYTHONIOENCODING utf-8 ENV TZ='Asia/Tokyo' # workdirの設定 WORKDIR /opt/ # 作業ディレクトリ作成 RUN mkdir /opt/src RUN mkdir /opt/data # apt-getのアップデートなど RUN apt-get -y update RUN apt-get -y clean RUN apt-get -y autoremove RUN apt-get -y upgrade RUN apt-get install -y apt-utils unzip RUN pip install --upgrade pip # Japanese Localization RUN cp /usr/share/zoneinfo/Asia/Tokyo /etc/localtime # google-chrome RUN wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | apt-key add && \ echo 'deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main' | tee /etc/apt/sources.list.d/google-chrome.list && \ apt-get update && \ apt-get install -y google-chrome-stable # ChromeDriver ADD https://chromedriver.storage.googleapis.com/92.0.4515.107/chromedriver_linux64.zip /opt/chrome/ RUN cd /opt/chrome/ && \ unzip chromedriver_linux64.zip # python package RUN pip install selenium && \ pip install bs4 && \ pip install oauth2client ENV PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/chrome # コンテナ起動時に実行するコマンドを設定 CMD [ "python", "/opt/src/test_202108qiitauserpagecheck.py" ] docker-compose.yml version: '3' services: selenium: container_name: "selenium" build: ./ volumes: - ./src:/opt/src - ./data:/opt/data ports: - "5001:5001" selenium.common.exceptions.SessionNotCreatedException: Message: session not created: This version of ChromeDriver only supports Chrome version $VERSION_CODE 【Python/Selenium】ChromeDriverバージョンエラー対処法 でまとめられているようにDocker環境を作っている最中にこのエラーに遭遇しました。 原因は、ChromeDriverをインストールする際に指定しているリンクがバージョンコードも指定していて、このバージョンをWebDriverがサポートできていないことらしいです。 にてダウンロードできるWebDriverのバージョンを確認できますが、このエラーに後に Current browser version is xxx.xxx.xxx.xxx のように対応できるバージョンが指定するかのように表示されて、このバージョンがchromedriver.storage.googleapis.comになかったりします。 そのときは、一つ古いバージョンをダウンロードすることでエラーが解消できました。 参考記事 Docker+Pythonを使ってスクレイピング環境を構築する Docker 内で Chrome とSelenium を使ったスクレイピング実行環境を構築してみた 第662回　Docker+Selenium ServerでWebブラウザ自動操作環境を作る まとめ これで、Selenium IDEで作ったテストコードをDocker化したSeleniumでE2Eテストできる環境ができました。 ですが、これで終わりではなく、 テストした結果をどのように可視化しないとE2Eテストの運用はできない テストコードを手動配置ではなく自動的に共有することで全自動化したいい などの課題があるので、試行錯誤中なので完成したら改めてこの記事を更新しようと思います。 DockerよりもJenkinsにSeleniumを実行するような環境があれば、正直そっちの方がいいと思いますw 　

M1　macとインテルMac、Windows環境が混在した場合に、Dockerが上手く使えなかったので、なんとか作ってみました。重要なのは、コンパイル部分を一つにまとめる事です。 以下の記事を参考にさせていただきました。 ソース RUN if [ $(uname -m) = "aarch64" ]; then \ echo arm64; \ # M1 Mac用 # インストールしたいパッケージのコマンドが入る && ./configure --build=arm \ && make \ && make install; \ else \ echo amd64; \ # それ以外のOS用 # インストールしたいパッケージのコマンドが入る && ./configure \ && make \ && make install; fi これで、今まで課題でGitで管理するのがめんどだった部分が無事解決しました。 M1 macはuname -mでaarch64という環境情報をはいてくれるのでこれを使います。

気持ち vagrant上に構築したDockerでLaravel環境の構築はできた。さあ次はデバッグ環境を整えるだけだ。アレ、どう設定したらええんや。 やりたいこと vscodeを使ってvagrant環境に接続し、dockerコンテナで実装したlaravel環境のデバッグをxdebugを使って実現する。 事前準備 vscodeからvagrant環境に接続する為の「Remote-SSH」拡張機能をインストールしておく vscodeでxdebugを使用する為の「PHP Xdebug」拡張機能をインストールしておく vagrant上でdockerをインストールしておく dockerでlaravel環境を構築しておく コンテナのlaravelのプロジェクトをdockerホストと共有しておく 流れ Vagrantfileに仮想マシンのIPアドレスの設定を記入する。 phpコンテナ※に接続し、xdebugのインストールを行う。 php.iniにxdebugの設定を記入する。 vscodeのlaunch.jsonの設定を編集する。 ※php:7.4-apacheというイメージから作成したコンテナを使用しています。 vscode上でvagrant環境にSSH接続する Windowsであれば/Users/ユーザ名/.ssh/configを開いて、Vagarntの作業ディレクトリ上で$ vagrant ssh-configを実行し出力結果を記入する。 $ vagrant ssh-config Host default HostName 127.0.0.1 User vagrant Port 2222 UserKnownHostsFile /dev/null StrictHostKeyChecking no PasswordAuthentication no IdentityFile ###ここには＜VirtualBoxの鍵ファイルのパス＞が出力される### IdentitiesOnly yes LogLevel FATAL Hostは任意の名前でOKです。 /Users/ユーザ名/.ssh/config Host vagrant_env HostName 127.0.0.1 User vagrant Port 2222 UserKnownHostsFile /dev/null StrictHostKeyChecking no PasswordAuthentication no IdentityFile ###＜VirtualBoxの鍵ファイルのパス＞を記入する### IdentitiesOnly yes LogLevel FATAL あとはvscodeの左側にあるメニューバーから「Remote Explorer」のアイコンをクリックして接続を進めればよい。 Vagrantfileに仮想マシンのIPアドレスの設定を記入する。 仮想マシンにIPアドレスを割り当てましょう。 以下の内容を追記します。 Vagrantfile config.vm.network "private_network", ip: "192.168.33.66" 上記IPアドレスは適当でOKです。 phpコンテナに接続し、xdebugのインストールを行う 以下のコマンドを実行し、xdebugのインストールをします。 $ pecl install xdebug $ docker-php-ext-enable xdebug # このコマンドを実行することでphp.iniファイル内にzend_extension=＜xdebug.soのパス＞を記載しなくて済む 私の環境ではxdebugのバージョンは3.0.4がインストールできました。 php.iniにxdebugの設定を記入する php.iniのパスは「/usr/local/etc/php/php.ini」になります。 ファイルを開いて以下の内容を追記します。 [xdebug] xdebug.mode=debug xdebug.remote_enable=1 xdebug.remote_autostart=1 xdebug.remote_connect_back=1 xdebug.start_with_request=yes xdebug.client_host=192.168.33.66 # Vagrantfileで設定した仮想マシンのIPアドレス xdebug.clent_prot=9003 xdebug.discover_client_host=1 xdebug.idekey="vscode" vscodeのlaunch.jsonの設定を編集する まずはdockerホストのlaravelプロジェクトのディレクトリをvscodeで開く。 そして左のメニューバーから「Run And Debug」アイコンをクリックして、「create a launch.json file」をクリックしてlaunch.jsonを作成する。 launch.jsonの内容を以下に書き換える。 { "version": "0.2.0", "configurations": [ { "name": "Listen for XDebug", "type": "php", "request": "launch", "port": 9003, "stopOnEntry": true, "serverSourceRoot": "＜コンテナのlaravelプロジェクトのパス＞", "localSourceRoot": "${workspaceRoot}" # laravelのコンテナと共有しているdockerホスト側のパス。 }, ] } あとはvscodeのデバッグを実行すればよい。

VOICEVOX 0.2.0 をUbuntu 21.04環境へインストールする の続き これまでの背景 前回の記事では、UbuntuでVOICEVOXを使うことができるようになりました。 同時に、フロントエンド側（VOICEVOXソフトウェア）の開発をするための環境整備ができました。 いっぽうで、APIサーバー側（VOICEVOXエンジン）については、必ずしもそうではありませんでした。 この数週間の試行錯誤から、現状について理解したことをまとめます。 結局エンジンは、製品版が必須（まだオープンソースになっていない部分がある） 公式READMEに書かれた手法を使って、製品版と開発中コードを組み合わせて実行できる これはWindowsのみサポート（バイナリは、Windows用にビルド済み） 既に知られているように、製品版はWineを使って実行可能 LinuxやmacOSでの動作例報告あり VOICEVOX（主にエンジン）をDockerコンテナ化する事例が、複数公開されている ということで、docker-composeを使って、製品版と開発中コードの組み合わせを一括起動・終了できるようにしてみました。 ▷GitHubリポジトリ UnisonUnum ドキュメント等、設定や使い方の説明を書けていないので、どなたでもすぐに使えるところまで作り込んでいないのですが、 Dockerやgitなどに慣れた方であれば、これを参考にして、開発環境の整備の手がかりになるのかなと思います。 方針 製品版のパッケージや展開後のサイズが非常に大きいので、コンテナ内にコピーせずに、volumeでマウントします サーバーのソースコードを開発しながら使う想定なので、これもvolumeでマウントします 製品版の前段に位置するサーバーでは、エンジンと同じFastAPI、Uvicornを使って実装します 今のところ単純にリクエストを後段へリダイレクトするだけの実装になっています 目的とする機能によっては、一度受けたリクエストを別途エージェントで中継するほうが良い 機能をmiddlewareとして実装することで、移植（エンジンに組み込む）できる（可能性がある） 今後は、VOICEVOXに独自の付加機能（連携するソフトウェア）を開発していきたい 構成図 実行時の記録（一例） (/PATH_TO/UnisonUnum/docker)$ docker-compose up Creating network "docker_default" with the default driver Creating docker_voicevox_engine_wine_1 ... done Creating docker_voicevox_engine_dev_1 ... done Attaching to docker_voicevox_engine_dev_1, docker_voicevox_engine_wine_1 voicevox_engine_dev_1 | INFO: Started server process [9] voicevox_engine_dev_1 | INFO: Waiting for application startup. voicevox_engine_dev_1 | INFO: Application startup complete. voicevox_engine_dev_1 | INFO: Uvicorn running on http://0.0.0.0:50021 (Press CTRL+C to quit) voicevox_engine_wine_1 | 0090:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded. voicevox_engine_wine_1 | 0090:err:winediag:nodrv_CreateWindow Make sure that your X server is running and that $DISPLAY is set correctly. voicevox_engine_wine_1 | 0090:err:systray:initialize_systray Could not create tray window voicevox_engine_wine_1 | 0024:fixme:seh:EnumProcessModulesEx (FFFFFFFFFFFFFFFF, 0000000000000000, 0, 0000000000988E80, 2) semi-stub voicevox_engine_wine_1 | 0024:fixme:seh:EnumProcessModulesEx (FFFFFFFFFFFFFFFF, 000000006042E270, 1672, 0000000000988E80, 2) semi-stub voicevox_engine_wine_1 | INFO: Started server process [32] voicevox_engine_wine_1 | INFO: Waiting for application startup. voicevox_engine_wine_1 | INFO: Application startup complete. voicevox_engine_wine_1 | INFO: Uvicorn running on http://0.0.0.0:50031 (Press CTRL+C to quit) voicevox_engine_wine_1 | INFO: 172.19.0.1:41238 - "GET /docs HTTP/1.1" 200 OK voicevox_engine_wine_1 | INFO: 172.19.0.1:41238 - "GET /openapi.json HTTP/1.1" 200 OK voicevox_engine_dev_1 | Namespace(host='0.0.0.0', port=50021, use_gpu=False, voicevox_dir=PosixPath('/opt/voicevox'), voicelib_dir=None, backend_endpoint='http://127.0.0.1:50031') voicevox_engine_dev_1 | INFO: 172.19.0.1:53220 - "POST /audio_query?text=%E9%9F%B3%E5%A3%B0%E5%90%88%E6%88%90%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%B3%E3%81%A7&speaker=0 HTTP/1.1" 307 Temporary Redirect voicevox_engine_wine_1 | INFO: 172.19.0.1:41252 - "POST /audio_query?text=%E9%9F%B3%E5%A3%B0%E5%90%88%E6%88%90%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%B3%E3%81%A7&speaker=0 HTTP/1.1" 200 OK

はじめに 前回はC言語のソースビルドについてdocker image の size を小さくする方法をメモリました。 今回は python についてです。忘れないうちにメモメモします。 内容 削減方法 docker image を build と実行用に分けるのは同じ考え方です。こちらのサイトで学ばせていただきました。 ここで紹介されているのは、 pip install --user を使う --user オプションをつけると、ホームディレクトリの.local に全ての必要なファイルがインストールされる。ので、これをコピーすればよい。 virtualenv を使う virtualenv で使用したディレクトリをコピーし、PATHを通す。 というものです。いずれもビルド用イメージでpip や virtualenv を実行し、実行用イメージに必要なものだけ持ってくるという作戦です。 実行例 おじさんは頑張って動かしたので、こちらにメモします。Flask を使いました。以下のファイルが全て同じフォルダにあれば、再現できるかと思います。 . ├── main.py ├── multi-stage.Dockerfile ├── requirements.txt └── single-stage.Dockerfile 通常のコンテナを作成 まず、実行するpython スクリプト。 main.py from flask import Flask app = Flask(__name__) @app.route('/') def hello(): return 'Hello World!' if __name__ == '__main__': app.run(host='0.0.0.0', port=8080, debug=True) pip でインストールするためのあれ。 requirements.txt Flask==2.0.1 そして、普通の?Dockerfile single-stage.Dockerfile FROM ubuntu:18.04 RUN apt-get update && apt-get install -y python3 python3-pip COPY requirements.txt . RUN python3 -m pip install --user -r requirements.txt RUN ls /root/.local/ COPY main.py /root/app/main.py EXPOSE 8080 CMD ["python3", "/root/app/main.py"] もちろん動きます。 $ docker build -f single-stage.Dockerfile -t py-single . $ docker run -p 5000:8080 --rm py-single ブラウザを立ち上げても良いですが、別のterminal で $ curl localhost:5000 Hello World! となります。 マルチステージ ここで、Dockerfile を変更します。pip install するとき、--user オプションをつけると、user の　~/.local/ というディレクトリにpython module が保存されます。なので、それをコピーする作戦です。 multi-stage.Dockerfile FROM ubuntu:18.04 AS compile-image RUN apt-get update && apt-get install -y python3 python3-pip COPY requirements.txt . RUN python3 -m pip install --user -r requirements.txt RUN ls /root/.local/ FROM ubuntu:18.04 AS build-image COPY --from=compile-image /root/.local /root/.local RUN apt-get update && apt-get install -y python3 COPY main.py /root/app/main.py EXPOSE 8080 CMD ["python3", "/root/app/main.py"] 同様に実行できます。 イメージサーズの比較 私の所では、こんな感じでした。 REPOSITORY TAG IMAGE ID CREATED SIZE py-multi latest bbdb7bfc547b 2 days ago 140MB py-single latest a16f61635f65 2 days ago 487MB 小さくなりました。良かった良かった。 まとめ python でも docker image の size を小さくする方法を調査し、動作確認した。pip install するとき、--user オプションをつけて、~/.local をコピーすればよい。 更に考えられるこの先の調査は pip でそもそも何がインストールされるのか、を理解できれば、必要なファイルを細かく選別できて、もっと小さくできるかもしれない virtualenv も試す ですが、とりあえず目的が達せられそうなので、これで良しとしました。 (2021/08/26 翌日の深夜1:22)

概要 docker-compose を使って即座に dnsmasq を構築する手順を記している. ここでは、私にとって最短手番での dnsmasq の起動手順を記す. なお、本手順は物理ホストの 53番ポートを解放済みであることを前提にしている. コンテンツ 実装時期 [01] docker-compose を使って即座に dnsmasq を構築する (構築手順のみ) 2021/08 [02] docker-compose を使って即座に dnsmasq を立てる (解説) 2021/08

Dockerのイメージとコンテナ　 1.イメージの取得、表示、削除 レジストリからイメージを取得 docker pull イメージ名 例）docker pulll イメージ名:バージョン指定可能 取得したイメージを表示、確認 docker images 取得したイメージを削除する docker image rm イメージ 省略)docker rmi イメージ 2.イメージからコンテナを作成,起動,停止,削除 コンテナの作成 docker create --name ○○○ イメージ名 詳細） --nameで名前を付けてから作成する コンテナの確認 起動中のコンテナ表示 docker ps すべてのコンテナ表示 docker ps -a コンテナの起動 docker start イメージ名 コンテナの停止 docker stop イメージ名 コンテナの削除 docker rm イメージ名 コンテナを全て削除 docker ps -a -q | xargs docker rm Nginxで作成されたページを確認する方法 docker create --name 指定名　-p 8080:80 nginx 詳細）８０８０：８０　　← ホストのポート：コンテナのポート 　　　　　　　　-p ← コンテナのポートをホストい結びつけ参照できる コンテナの作成と起動を一緒に行う 例）Nginxの場合 docker run --name 指定名　-p 8080:80 -d --rm nginx 詳細）　　-d ← バッググラウンドで行う 　　　　　　　　　　-rm ← 停止されたら削除も行う

Dockerややこしポイント RUN? START? BUILD? 何で何してるかわからん 最初Dockerというものを知ったときに持っていた印象は 「なんか好き勝手遊ぶ環境が手に入るんだろうなぁ」でした 実際そうはそうなのですがその遊ぶ環境(コンテナ)を手に入れるために取る手順がよくわからず困ったので それについて簡単に覚書を書いておきます。 とりあえず用語をまとめておく Image コンテナを立ち上げるための情報が詰まったもの こいつ自体はDockerHub　とかからでも引っ張って来れるしDockerfileから作ることも可能 Docker file Imageを作るための定義書 DockerHubにあるイメージもみんなが自分の環境でBuildしたDockerfileのImageをあげてる 人のやつ使ったことないからわかんないけど多分すごいんでしょう Build Docker FileからImageを作るためのコマンド こいつを最初見た時からこのコマンドでコンテナを立ち上げると思ってしまってずっとDokcer FileとImageの関係性がわからなかった こいつはコンテナの元になるImageを作るだけ！ RUN コンテナを立ち上げてスタートさせるコマンド こいつもこいつでややこしい名前 このコマンドでやっとImageからコンテナを立ち上げて起動することができる いきなりDocker File作ろうとするな 小生基本的にアプリケーションばかり作ってきた人間ですのであまりLinuxについて詳しくありませんでした。 最近になってコマンド打ちながら頭の中でPCの状態を思い描けるくらいの感じ なのでいきなりDokcer FIle作って環境のImage作るぜ！ってなってもいまいちイメージが掴めずあたふたしちゃいました なので初めてDocker FIle作るよ〜って人は一回基本のImageだけパクってきて それでRUNしてコンテナの中入ってその中でわちゃわちゃインストールするのを試してみるのがいいと思います。 実際初めて作った時のコードまとめておきます。 # ポート開けたpython3のImageからpython_1stっていうコンテナを立てた docker run -d -it -p 8080:80 --name python_1st python:3 # コンテナの中に入った docker exec -it python_1st /bin/bash # UbuntuだったのでaptをUpdate apt update -y # Djangoをインストール pip3 install Django # Nginxをインストール apt install -y nginx # HTML直接書くためにHTMLをインストール apt install -y vim # HTMLをvimで作ってHello Worldだけ書く vim /var/www/html/test.html # Nginxを起動させる service nginx start # HTMLがChromeで確認できたら閉じる service nginx stop こんな感じ でも毎回こんなんするんだるいからこれらのupdateしたりinstallしたりした結果をImageとして Docke Fileから作ってそのImageでコンテナを立ち上げることでこれらの処理をなくして毎回同じ環境を作れるようにするというのがDockerの魅力の一つっぽい 頭の中スッキリしたのでいったんここでまたオリジナルDockerFile作り終わったら続き書くかも

本シリーズのトップページ https://qiita.com/robozushi10/items/e2ed733e09c9e39407f2 概要 docker-compose を使って即座に dnsmasq を構築する手順を記す. 本項の内容は、前項 の解説である. 参考にした記事 ・https://qiita.com/tac0x2a/items/c6306b95dd27703bc975 ・https://sites.google.com/site/hollyroyaltea/home/dns/dnsmasq 事前準備するファイル 次の構成でファイルを用意しておく. ファイルの中身については後述する. . |-- PV | `-- etc | `-- dnsmasq.d | |-- my.conf ...... dnsmasq コンテナ内の /etc/dnsmasq.conf から読み込まれる | `-- add_hosts .... 上記 my.conf から読み込まれる `-- docker-compose.yml ファイルの中身 docker-compose.yml 重要な点についてはファイル内にコメントを記した. version: '3' services: dnsmasq: restart: always image: 4km3/dnsmasq container_name: mydnsmasq environment: TZ: "Asia/Tokyo" ports: - "53:53/udp" - "53:53/tcp" # PC を DNS に登録したい場合は ./PV/etc/dnsmasq.d/add_hosts を編集する volumes: - './PV/etc/dnsmasq.d:/etc/dnsmasq.d' dns: # 本ファイルの「dns」に対して、上位の DNSサーバを定義してしまえば、 # PV/etc/dnsmasq.d/my.conf に上位 DNSサーバを定義する手間が省ける. - 8.8.8.8 - 127.0.0.1 cap_add: - NET_ADMIN PV/etc/dnsmasq.d/my.conf /etc/dnsmasq.d/. に対して、*.conf というファイル名で配置しておけば、 設定ファイルとして読み込まれるので、ファイル名は自由である. 設定値については、「/etc/dnsmasq.conf」から必要な設定のみを取り出して再定義しただけである. # プライベートIPの逆引きは上位DNSに転送しない bogus-priv # 名前と IP の管理を、/etc/hosts ではなく /etc/dnsmasq.d/add_hosts に変更する. # (∵ コンテナ内の /etc/hosts は、ホスト側から容易にマウントできないため) addn-hosts=/etc/dnsmasq.d/add_hosts ? # 後述の「domain=」で指定されたドメインで補完する. expand-hosts # 補完するドメイン. ここでは「mylocal.domain」としているので適宜読み替えること. domain=mylocal.domain PV/etc/dnsmasq.d/add_hosts 本ファイルに、PC の IP と マシン名を定義していくことになる. なお、本ファイルは上記 ? によって読み込まれる. ここでは、IP「10.208.200.123」とマシン名「piyo」を関連付けしている. 10.208.200.123 piyo 運用方法 起動 docker-compose up -d を実行するのみである $ docker-compose up -d 起動したら、(コンテナを稼働させた PC で) 次のようにして確認すれば良い. ## dig 解決させたいマシン名 @<dnsmasq コンテナを稼働させているホストのIP> $ dig piyo @127.0.0.1 $ dig piyo.mylocal.domain @127.0.0.1 IPとマシン名の追加・変更・削除 PV/etc/dnsmasq.d/add_hosts を編集してから次を実行すれば良い $ vim PV/etc/dnsmasq.d/add_hosts (編集する) $ docker-compose restart 以上.

本シリーズのトップページ https://qiita.com/robozushi10/items/e2ed733e09c9e39407f2 概要 docker-compose を使って即座に dnsmasq を構築する手順を記す. ここでは、私にとって最短手番での dnsmasq の起動手順を記す. 説明については、[02] に記した. なお、本手順は物理ホストの 53番ポートを解放済みであることを前提にしている. 手順 初回起動 ## docker-compose.yml など一式を clone する $ git clone https://github.com/robozushi10/qiita-dnsmasq.git $ cd qiita-dnsmasq $ vim PV/etc/dnsmasq.d/add_hosts ## /etc/hosts と同じ要領で記述する 10.208.200.123 piyo $ docker-compose up -d これで、物理ホストの IP と 53 ポートを DNSサーバとして使用すれば 名前解決ができるはずである. IPとマシンの定義を変更したい場合 $ vim PV/etc/dnsmasq.d/add_hosts (IPとマシン名を定義する) $ docker-compose restart 以上.