確認環境 Docker Desktop 4.4.4 (73704) 経緯 いつものようにDockerコンテナを起動しようとしたら、何やらUnauthorizedといわれる。 直前にDocker Desktopのアップデートをかけたからか・・・？ 今日付けでOrganizationにアカウントが紐づけられたからその影響もあるかもしれない。 $ docker-compose up -d --build [+] Building 7.9s (4/4) FINISHED => [internal] load build definition from Dockerfile 0.0s => => transferring dockerfile: 32B 0.0s => [internal] load .dockerignore 0.0s => => transferring context: 2B 0.0s => ERROR [internal] load metadata for docker.io/library/php:8.0-fpm 7.8s => [auth] library/php:pull token for registry-1.docker.io 0.0s ------ > [internal] load metadata for docker.io/library/php:8.0-fpm: ------ failed to solve: rpc error: code = Unknown desc = failed to solve with frontend dockerfile.v0: failed to create LLB definition: failed to authorize: rpc error: code = Unknown desc = failed to fetch oauth token: unexpected status: 40 1 Unauthorized 試したこと ログインし直せばいいのでは？と思い、 docker login コマンドを叩くも、アクセストークンを使いなさいと言われる。 $ docker login Authenticating with existing credentials... Stored credentials invalid or expired Login with your Docker ID to push and pull images from Docker Hub. If you don't have a Docker ID, head over to https://hub.docker.com to create one. Username (nagayoshi): Password: Error response from daemon: Get "https://registry-1.docker.io/v2/": unauthorized: please use personal access token to login そういや2要素認証設定したから、もしかしてアクセストークンを生成しないといけない・・・？そんなめんどうなことある・・・？ 解決方法 Docker Desktop上でログインし直すことで解決した。アクセストークンは必要なかった！ Docker Desktop上で Sign out する。ブラウザが起動してログアウトしたことを知らされる。 再びDocker Desktop上で Sigh in する。ブラウザが起動してユーザID/PW、2要素認証していればAuthentication Codeを求められるので、画面に沿ってログインする。 数日の間Docker使う機会がなかったんだけど、いつのまにかZoomのリンク開いたときみたいになってたのか。気になって調べたけど、リンクをクリックしたときにアプリケーションが起動して特定のコンテンツに遷移する仕組みのことをディープリンクというらしい。

構築する環境 PHP8.0 Apatch2 MySQL8.0.20 Laraval8 Docker ディレクトリ構造 プロジェクトフォルダ ┣━ docker ┃ ┣━ MySQL ┃ ┃ ┗━ Dockerfile ┃ ┗ php ┃ ┣━ 000-default.conf ┃ ┣━ Dockerfile ┃ ┗━ php.ini ┗━ docker-compose.yml Dockerfile 000-default.conf Dockerfile php.ini docker-compose.yml の４つのファイルを作っていきます。 以下、コピペでOKです。 Dockerfile(MySQL) FROM mysql:8.0.20 Dockerfile（PHP） # どんなdockerイメージを利用して構築をするか FROM php:8.0-apache RUN cd /etc/apache2/mods-enabled \ && ln -s ../mods-available/rewrite.load # 設定ファイルをdockerコンテナ内のPHP、Apacheに読み込ませる ADD php.ini /usr/local/etc/php/ ADD 000-default.conf /etc/apache2/sites-enabled/ # Composerのインストール RUN cd /usr/bin && curl -s http://getcomposer.org/installer | php && ln -s /usr/bin/composer.phar /usr/bin/composer # ミドルウェアインストール RUN apt-get update \ && apt-get install -y \ git \ zip \ unzip \ libzip-dev \ vim \ libpng-dev \ libpq-dev \ libfreetype6-dev \ libjpeg-dev \ libonig-dev \ && docker-php-ext-install pdo pdo_mysql mysqli zip RUN docker-php-ext-configure gd \ --with-freetype=/usr/include/ \ --with-jpeg=/usr/include \ && docker-php-ext-install -j$(nproc) gd ENV COMPOSER_ALLOW_SUPERUSER 1 ENV COMPOSER_HOME /composer ENV PATH $PATH:/composer/vendor/bin COPY --from=composer:latest /usr/bin/composer /usr/bin/composer RUN composer self-update --2 RUN curl -sL https://deb.nodesource.com/setup_12.x | bash - RUN rm -rf node_modules RUN apt-get install -y nodejs RUN npm install npm -g n --save-dev cross-env RUN npm cache clear --force RUN npm install webpack --save RUN npm install node-sass --nodedir=/usr/bin/node WORKDIR /var/www/ 000-default.conf docker/php/000-default.conf <VirtualHost *:80> ServerAdmin webmaster@localhost DocumentRoot /var/www/public ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined <Directory /var/www/public> AllowOverride All Require all granted </Directory> </VirtualHost> php.ini こちらの記事を参照させていただきました。 docker/php/php.ini [PHP] zend.exception_ignore_args = off expose_php = on max_execution_time = 30 max_input_vars = 1000 upload_max_filesize = 64M post_max_size = 128M memory_limit = 256M error_reporting = E_ALL display_errors = on display_startup_errors = on log_errors = on error_log = /var/log/php/php-error.log default_charset = UTF-8 [Date] date.timezone = Asia/Tokyo [mysqlnd] mysqlnd.collect_memory_statistics = on [Assertion] zend.assertions = 1 [mbstring] mbstring.language = Japanese docker-compose.yml docker-compose.yml version: '2' services: db: build: ./docker/mysql ports: - "33306:3306" environment: MYSQL_ROOT_PASSWORD: root MYSQL_USER: root MYSQL_PASSWORD: root MYSQL_DATABASE: tsurikomi volumes: - ./docker/mysql/data:/var/lib/mysql - ./docker/mysql/initdb.d:/docker-entrypoint-initdb.d php: build: ./docker/php ports: - "8080:80" volumes: - ./src:/var/www depends_on: - db Docker コンテナのビルドと起動 ビルド docker compose build 起動 docker compose up phpコンテナに入る docker compose exec php bash Laravel8のインストール 以下、phpコンテナ内でのコマンドです composer create-project "laravel/laravel=8.*" ./ 最後、./とすればsrcの直下にLaravelのファイル群を作成することができる php artisan -V でLaravelのバージョン確認 インストールできているか確認できたら、localhostで動くか確認する http://localhost:8080/ この画面が出たら成功！ もしエラーが出たら、この辺の記事を参考に。 最後に この後、プロジェクトを進める手順をまとめる予定です。 ポートフォリオを作りながらちょくちょく進めていきます。

先日の記事で紹介した LocalStack Docker コンテナを利用したローカル AWS 環境に DynamoDB サービスを追加して コンテナ起動時にテーブルを自動作成するようにする方法です Docker の設定 docker-compose.yml version: '3.8' services: localstack: container_name: localstack image: localstack/localstack:0.13.3 environment: SERVICES: dynamodb INIT_SCRIPTS_PATH: /docker-entrypoint-initaws.d DEFAULT_REGION: 'ap-northeast-1' ports: - '4566:4566' volumes: - ./init:/docker-entrypoint-initaws.d - ./json:/json 環境変数(environment) SERVICES に dynamodb を追加 INIT_SCRIPTS_PATH はコンテナ起動時に自動的に実行されるシェルスクリプトのディレクトリを指定します volumes ホスト側の init ディレクトリをコンテナの /docker-entrypoint-initaws.d (環境変数INIT_SCRIPTS_PATHで指定したパス)にマウントしています ホスト側の json ディレクトリをコンテナの /json にマウントしています テーブル定義 JSON テーブル定義 JSON ファイルを作成し、json ディレクトリに保存 json/todo.json { "TableName": "todo", "AttributeDefinitions": [ { "AttributeName": "id", "AttributeType": "S" } ], "KeySchema": [ { "AttributeName": "id", "KeyType": "HASH" } ], "ProvisionedThroughput": { "WriteCapacityUnits": 5, "ReadCapacityUnits": 10 } } 以下のコマンドで JSON ファイルのスケルトンを生成することができます aws dynamodb create-table --generate-cli-skeleton テーブルを作成する初期化スクリプト cli-input-json オプションでテーブル定義 JSON ファイルを指定して create-table を実行するスクリプトを作成し init ディレクトリに保存 init/create-dynamodb-table.sh #!/bin/bash # テーブルを作成 awslocal dynamodb create-table --cli-input-json file:///json/todo.json # テーブル一覧を表示 awslocal dynamodb list-tables コンテナ起動 docker compose up -d CLI でアイテムを登録・取得してみる localstack コンテナ内で実行 # コンテナ内のシェルを実行 docker compose exec localstack bash # アイテムを登録 awslocal dynamodb put-item --table-name todo --item '{"id":{"S":"0001"},"title":{"S":"Qiita記事を書く"}}' # アイテムを取得 awslocal dynamodb get-item --table-name todo --key '{"id":{"S":"0001"}}'

はじめに そろそろ移行するべ1と起動手順とかのスクリプト設定を自分で書いてみた。せっかくだから Qiita に投稿しようかなと思って検索したら、やはり皆さん同じことを考えているようで大体同じ感じでした。二番煎じなんだろうけど若干異なる部分もあえて投稿してみます。 なお、 WSL2 側のディストリビューションは Ubuntu 20.04 自分はGUI操作を行わないので不要なので代替UIは不要 k8s も使わないのでk8sは不要 という感じです。 削除手順 Docker Desktop は普通にコントロールパネルから削除する。 WSL2 側に Docker Desktop が設定したと思われる docker グループが作成されていると思うが、これは後で使うのでそのまま残しておく。 $ cat /etc/group | grep ^docker docker:x:1001:username Docker Engine インストール こちらも通常のUbuntuへのインストール手順で 起動設定 今現在の WSL2 は Systemd などからサービス起動が行われないので、シェル起動時に実行する。~/.bash_profile に記載したいが他のシステムとドットファイル郡を同じにしたいというのもあるので、WSL2 かどうかを確認し、Docker の PIDファイルが用意されていなければ起動するというようにした。 # WSL2 + Docker if [[ "$(uname -a)" =~ ^Linux.*-microsoft-standard.*GNU\/Linux ]]; then if [ ! -f "/var/run/docker.pid" ]; then sudo /usr/sbin/service docker start fi fi これだけだと、sudo時にパスワードを聞かれるので使い勝手が悪い。 ここで、Docker Desktopが残してくれた docker ユーザーグループがあるので、dockerグループ(%docker)のみサービス起動のパスワードを聞かない(NOPASSWD)ようにsudoersに設定する。 $ sudo visudo -f /etc/sudoers.d/docker %docker ALL=(ALL) NOPASSWD: /usr/sbin/service docker start Docker Compose Ubuntu の apt で入るものは古いので brew で入れる。Homebrew が入ってない人はまずそこから。 $ brew install docker-compose ということで、自分が使う範囲ではOKになりました。 Docker Desktopが有料化、2022年1月31日までが猶予期間 - Docker is Updating and Extending Our Product Subscriptions ↩

はじめに 世のDockerの入門者向けの解説は、技術初心者に対してあまりにも広範でマニアックな前提知識を要求します。にもかかわらず、多くの解説では、技術初心者の立場からすると概念や用語の説明について十分にカバーされているとは言い難く、混乱を招くことが少なくありません。この記事では、Dockerに登場する初歩的な概念を勉強する過程で技術初心者がつまづきがちな概念を解説します. ※注意 筆者は技術の専門家ではなく、勉強中の身ですので、本記事には間違った記述が多分に含まれることが予想されます. 利用する際は参考程度にとどめ、必ず他の信頼できるソースを当たることを強くおすすめします. 技術初心者がつまづきがちな用語一覧 アタッチとデタッチ アタッチおよびデタッチは、主に「仮想化」や「クラウド」という技術が絡む文脈で使用される専門用語.「アタッチする」は「取り付ける」と言い換えられ、「デタッチする」は「切り離す」と言い換えられることが多い. 「仮想化」というものをする際に、「ボリューム(ストレージ)を割り当てる」ということをする.その動作のことを「アタッチ」という. 「デタッチ」はアタッチの逆で、ボリュームの割当を解除することをいう. つまり、アタッチすることでコンテナはホストOSに対してボリュームマウントすることができ、コンテナはホストOSが持つDocker関連のリソースにアクセスすることが出来るようになる. アタッチすることで利用するリソースのうち代表的なものには、「ホストOSの標準入出力」(=シェル,コンソール)がある. より実際的には、「アタッチ/デタッチ」は「ホストOSの標準入出力とコンテナをくっつける/切り離す」ことを意味することが多い. コンテナを稼働させるとき、「アタッチモード」と「デタッチモード」のどちらで動かすか指定する必要がある. 「アタッチモード」でコンテナを起動するには、dockerコマンドのattachを使う.これにより、ホストOSのコンソールからコンテナのコンソールにカーソルが明け渡され、ホストOSのコンソールを通してコンテナのコンソールを操作出来るようになる.このことは「コンテナの中に入る」と表現されることが多い. ここで、「デタッチモードではホストOSのコンソールとコンテナが切り離されているのだから、操作が出来ないのではないか？なぜそんなものがあるのか？」という疑問を持つのは自然である. しかし、以下に述べるような事情により、デタッチモードで起動しなければならない場合があることがある. また、後述のように、「擬似端末(pseudo-TTY)」という技術と「インタラクティブモード」という機能を用いることで、デタッチモードでありながらホストOSからコンテナを操作する方法があり、それを使用するのがdockerではデファクトスタンダードとなっている. 一旦話を戻すと、大まかにいうと、アタッチモードはフォアグラウンドで、デタッチモードはバックグラウンドでコンテナを実行するということになる. たとえば、サーバーとして動くコンテナ(以下「サーバーコンテナ」)をアタッチモードで起動すると、サーバーコンテナが稼働している間にホストOS側のコンソール(Windowsならコマンドプロンプト、Linuxならbashなど)はサーバーコンテナに支配され、コンソールで別の操作をすることができなくなる. Enterキー押そうものなら、たちまちサーバーコンテナが終了して消滅してしまう. コンソールをもう一つ起動すればアタッチモードでも引き続き操作可能だが、窓を沢山開いていると煩わしい. しかし、サーバーコンテナをデタッチモードで起動した場合、サーバーコンテナをバックグラウンドで稼働させることができ、今まで操作していたコンソールで引き続きコンテナを操作することが出来る. したがって、コンテナを起動する場合は、通常はデタッチモードで起動する場合が多い. しかし、デタッチモードではホストOSとコンテナが切り離されているので、ホスト側から対話的に指示を与えることはできない.つまり、このままでは、ほったらかしにしてても自動的に勝手に動くサービスしかデタッチモードでは稼働できない. ここで、「デタッチ=ホストOSのコンソールとコンテナを切り離しているにも関わらず、ホストOSのコンソールからコンテナを操作する」を実現するために、先に述べた「擬似端末(pseudo-TTY)」と「インタラクティブモード」を使う. 擬似端末を使うオプションは-t、インタラクティブモードを使うオプションは-iであり、-itというオプションで両方同時に使うことが出来る. ちなみにデタッチモードで起動する時は-dをつける. デタッチモードで、擬似端末とインタラクティブモードを同時に使いたい場合は-itdとすればよい. ひとまずは、「デタッチモードでコンテナを対話的に操作したい場合は、起動時に-itdをつける」と覚えておけばよい. コンテナをアタッチモードで起動するか、デタッチモードで起動するか、対話的なデタッチモードで起動するか、は、そのコンテナの用途によって異なる. ケース1:例えばJupyterlab上でプログラミングしたい場合は、Jupyterlabを起動するDockerイメージを作る.コンテナはサーバーとしてバックグラウンドで動かしていれば良いので、単に普通のデタッチモードでコンテナを作成・起動すればよい.起動中のJupyterlabに入りたければ、ホストOSからwebブラウザを開いて、そのサーバーコンテナのポート番号(をホスト側にマッピングしたもの)をURL窓に入力すれば接続できる. デタッチの重要性/しないとどうなるか アタッチとデタッチ プロセス 「プロセス」は情報処理のことで、具体的には「プログラムの動作中のインスタンス」を意味する.(インスタンスとは、プログラミングにおいて、クラスから生成される実体あるオブジェクトのことである.詳しくはプログラミングにおける「クラス」を勉強されたし.) 例えば、wordを起動してwordファイルを編集するとき、そのwordファイルの編集用の「作業ファイル」が作成され、編集作業の間は存在し続ける.(wordのアプリを閉じると同時に削除される) この作業ファイルは正に「プログラムの動作中のインスタンス」=「プロセス」である. 「プロセス」は「プログラムのコードおよび全ての変数やその他の状態」を含む. プロセスを実行する主体は「Windows、Mac、Linux等のOS」だったり「コンテナ」だったりする. 我々はパソコンで文章を書く時、「メモ帳」というアプリを実行するが、これは一種の「プロセス」である. メインプロセス メインプロセスとは、「コンテナーそのものが起動させるプロセスすべてを管理するプロセス」のことをいう. 基本的には、「メインプロセス」=「bashなどのコマンドラインツール」だと思えばよい. コマンドラインツール以外のメインプロセスとしては、「webサーバー」や「DBサーバー」などが挙げられる. 例えば、「bashをメインプロセスとしてコンテナを起動し、mysqlを実行する」時は、以下のようなコマンドを打てばよい. docker run -it --entrypoint /bin/bash mysql ENTRYPOINTの代わりにCMDを使うこともある. 「メインプロセス」という用語について直接的に解説している文献は絶望的に少ない. 「メインプロセス」の意味の大要を掴むには、たとえば以下のリンク先で「メインプロセス」というワードで文書内検索を実行するとよい. メインプロセスとは1 メインプロセスとは2 メインプロセスとは3 ボリューム まず、コンテナの動作機構について述べる. コンテナは、あるプロセスを実行したい時に生み出され、プロセスの実行が終わった時点で消滅する. つまり、コンテナは基本的にはプロセスの実行とともに使い捨てられるものであり、パソコンがついている間はずっと動き続けているものではない. これは、パソコンで何か文章を書く時に「メモ帳」アプリを開いて作業をし、書き終わり次第「メモ帳」アプリを閉じて終了することと似ている. その際に書いた文章は「メモ帳」アプリ自身が覚えているわけではない.文章を残しておきたければ、.txtファイルとしてPCのどこかのディレクトリに保存しておく必要がある. "C:\Users\Yamada\文章"というディレクトリを作ってそこにメモ帳で書いた.txtファイルを保存したとする. このとき、この"C:\Users\Yamada\文章"というディレクトリはメモ帳から見れば「外部ストレージ」である. これと同じように、Dockerなどのコンテナ作動ソフトにおいて「コンテナ」および「コンテナが実行するプロセス」に対して、その過程で作られたファイルを保存しておくためには「外部ストレージ」が必要であり、それを「ボリューム」という. 標語的に言えば「ボリュームとは、Dockerコンテナで扱うデータを永続化する仕組みをいう」となる. Dockerの中に「ボリューム」というデータを保持する領域を確保して永続化する. ボリュームの実体はディレクトリで、DockerをインストールしたときにホストOS上に作られたDocker関連のディレクトリ内のどこかに存在する. Windowsの場合は、\\wsl$\docker-desktop-data\version-pack-data\community\docker\volumesにあるが、なぜかエクスプローラーからしかアクセス出来ない.詳しくはここやここを参照. docker inspectというコマンドを使うと/var/lib/docker/volumes/にあると表示されるが、これは嘘である.Windows上にこのようなディレクトリは存在しない. ボリュームへのアクセスの仕方は、通常のディレクトリにアクセスする仕方と少し仕組みが違う. ボリュームには2種類があって、ホストから覗けるものと、ホストからは覗けないがDockerからは覗けるもの、がある. ボリュームをどこのディレクトリに作成するかは、Dockerイメージを作成する際に定義する. ボリュームはコンテナで扱うデータの保存先であるから、当然コンテナから度々アクセスするため「マウント」の対象である. 「名前付きボリューム」という機能を使う場合が多いが、使い方がわかりにくいので注意が必要である. マウント 「マウント」を理解するにはまず、「ディレクトリ」という概念をよく理解する必要がある. PC上のある「場所」のデータを参照する際に、その場所の住所として「ディレクトリ」というものを定義する. ディレクトリ=住所の定義の仕方は、個々のOSによって異なる. コンテナ上ではOSが動いているから、ホストOS上でコンテナが動いているとき、パソコンの上には2つの異なるOSが動いている、という構図になる. すると、パソコン上のある場所を指定するための「住所」=「ディレクトリ」は、ホストOSのものとコンテナのものの2通りがあるはずである. ホストOSのものを「ホストディレクトリ」、コンテナのものを「コンテナディレクトリ」と呼ぶ. 「コンテナ」(または「仮想化」)を使う際に、ホストOSとコンテナ(またはホストOSとハイパーバイザー)の間で「通信」が行われる. ここで、同じ場所を表す「ホストディレクトリ」と「コンテナディレクトリ」の対応を付けたほうが便利であると考えるのは、自然である. ホストディレクトリとコンテナディレクトリの対応付けは、Dockerイメージを作成する際に行う. 「マウント」とは、ホストディレクトリとコンテナディレクトリを対応付けることで、コンテナの外にあるホストOSのデータをコンテナの中で利用できる状態にする機能のことである. マウントには、「ボリュームマウント」と「バインドマウント」と「一時ファイルシステムマウント」の3種類がある. 「ボリュームマウント」はDocker関連のフォルダやファイルにのみアクセスできるマウント、「バインドマウント」はホストが持つ全てのフォルダやファイルを読み書き出来るマウント、「一時ファイルシステムマウント」はDocker上に保存したくないファイルに一時的に利用できるようにするマウントである. 上の三者は用途によって使い分ければ良いが、特に理由がなければボリュームマウントを使うのが推奨されている. 「マウント」は、より一般には「外部に存在する、あるいはより低層の物の支配下にあるリソースにアクセス出来る状態にすること」を意味する. コンテナ 「コンテナ」とは、「プロセスだけを分離して動かす技術」またはそれを行う主体のことをいう. 通常はWindows、Mac、LinuxなどのOSがプロセスを動かすが、あえてOSが直接動かすことをせず、動かす役をコンテナに委託する、というイメージである.これを「コンテナ型仮想化」「コンテナに乗せる」「コンテナ上で動かす」などと表現する. 例えば、我々がパソコンで文章を書く時に使う「メモ帳」というアプリは、通常はWindowsのOS上で実行するが、これをコンテナに渡してコンテナ上で実行することが出来る. コンテナを使うと、メモ帳で文章を書くだけでなく、Pythonでプログラムを書くとか、Power Pointでプレゼン資料を作成するとか、複数の様々なプロセスを組み合わせたものを同時に実行することもできる さらに、コンテナの中でUbuntuなどの小さなOSを一瞬だけ起動して、その上でLinux専用のアプリを動かして作業して、作業が終わり次第OSともども終了することも出来る. つまり、コンテナを使うと、その場でその場で「環境のインスタンス」を生成し、その閉じた空間の中で作業を完結させることが出来る. 小さなコンピューターを持ってきてちょっと作業して撤収する、といっても良い これら全ての出来事は、「プロセス(の集合)」として処理される. コンテナはOSの上に乗っている. コンテナはOSから委託されたプロセスを自分自身で実行する. カーネルはベースとなるOS(ホストOS)が使っているのと同じものを共有する(「仮想化」の場合は「仮想マシンのカーネル」があるので、共有しない) コンテナの隔離性 コンテナは、基本的にそのコンテナの中にあるデータだけを利用できるようになっており、必要に応じて「マウント」をすることでホスト側に保存されたデータにアクセスする、という形をとる. ボリュームマウントを使ってコンテナからホスト側のフォルダやファイルを除いた場合、Docker関連のフォルダやファイルのみが表示され、他のものは隠しファイルのようになって見えなくなっている. なぜ基本的にはコンテナの中にあるデータしか使えず、ボリュームマウントをしてもコンテナからアクセスできるデータを制限しているかというと、このようにしてコンテナを「隔離」することにより、コンテナ内の環境のホストへの依存度を下げるためである. しかし、依存度が低すぎて不便な場合もあり、そういう時はバインドマウントを使うなどすると良い. コンテナと仮想化の関係 コンテナは、仮想化の一種とも言えるし、仮想化の機能のうち一部だけ(「プロセスだけを分離して動かす技術」)を取り出して簡素化したもの、ともいえる. 仮想化はOSの上に独立した閉じた環境を作って作業するという点で コンテナと同じだが、本格的にOSを入れて環境を生成するので、コンテナよりも拡張性があり壮大である. しかし、コンテナの方が簡素なので動作が軽い. 仮想化 「仮想化」とは、「OSの上で別のOSを動かしたい」という要望を叶えるための技術. OSの上に直接別のOSをインストールするのは色々難しいので、間にクッションを挟む必要がある. そのクッションのことを「ハイパーバイザー」という. 「ハイパーバイザー」は、より一般には「ゲストマシン」「ゲスト」「仮想マシン」「仮想化ソフト」などと呼ばれることが多い. ハイパーバイザーの上にインストールされた第2、第3のOSのことを「ゲストOS」という. 仮想化はOSの上に独立した閉じた環境を作って作業するという点で コンテナと同じだが、本格的にOSを入れて環境を生成するので、コンテナよりも拡張性があり壮大である. なぜDockerにはWSLが必要なのか Dockerは本来Linuxの上でしか動かないコンテナ仮想化ソフトウェアだからである. Windows用のDockerはWSLのおかげでWindowsでも動作出来る. なので、WindowsのPCにDockerを入れるには、予めWSL(2022年1月現在はWSL2)がインストールされている必要がある. DockerfileとDocker-composeの違い/関係 Dockerfileは「DockerImageの作成手順、構成情報」、Docker-compseは「コンテナの作成と起動方法、ネットワークを使ったコンテナ同士の連携」を定義するもの. Docker-composeの有用性と簡単な使い方については、ここやここを参照. 例えばcentosのベースイメージにWordpressとMySQLとTeXなど複数のアプリケーションをインストールするようなDockerfileを書く場合を考える. 通常のやり方では一個のDockerfileで全てのアプリを一元管理しなければならないが、Docker-composeを使うと、Wordpress用のDockerfile、MySQL用のDockerfile、TeX用のDockerfile、というふうに、アプリ毎にDockerfileを分けることができ、管理がしやすくなる. 今の時代はいきなりDocker-composeを使う方が色々と便利. もしDocker-composeの書き方だけでなくDockerfileの書き方もちゃんと勉強したいという場合は、Docker-composeに全てを書くのではなく、アプリ毎にDockerfileを書いて、Docker-composeでdockerfileを指定するようにすればよい. 今の時代は90％以上の人々はいきなりDocker-composeを使ったやり方を取っているので、Docker-composeを使うことは避けられない. 技術初心者は細かい設定を追っていると大変なので、無視して構わない. 参考文献 プロセスについて ゲストとは 仮想化を利用したことがない人のための仮想化の説明 ボリュームについての補足 マウントとは コンテナの隔離性について

はじめに GitHubでcloneしたLaravelプロジェクトをDockerで環境構築したい人に向けて簡潔に手順を解説します ５分程度で終わります １．リモートリポジトリをローカルにcloneしてbuildする #GitHubからcloneする $ git clone {リポジトリURL（https://〜.git} # イメージを作成 $ docker-compose build #cloneしたディレクトリに移動してbuild $ docker-compose up -d ２．パッケージのインストール ・Dockerコンテナ内に入って以下のコードを実行 $ docker-compose exec {サービス名} bash $ composer install 3.APP_KEYの作成 $ chmod 777 -R storage/ $ cp .env.example .env $ php artisan key:generate 4.localhostでウェルカムページを確認 localhost 上記の画像が表示されたら完了です！ おわりに GitHubからcloneしたLaravelプロジェクトはDockerでビルドしたらすぐに開けるものかと思ってた、、

 初めに なぜDockerなのか？ Dockerは、バーチャルで使えるパソコンです。なので、ネットを経由して持ち運べます。したがって、自分の作った環境と同じ環境を、会社のパソコン、新しく買ったパソコンで構築することができます。例えば、Macの上にDocker（仮想環境）を構築すればwindowsやLinux環境を構築することができます。また、Dockerはバーチャルなので、環境構築が上手くいかなくなった時や捨ててやり直すことができます。また、必要なくなった時にいつでも捨てることができます。このDockerは、今やエンジニアの必須のツールとなっています。そこで今回は、最速でPythonのデータ分析の環境構築します。Mac上に、UbuntuというLinuxのOSを立てて、そこにAnacondaをインストールします。そして、JupyterLabを立ち上げるまで行います。 今回の章立て Dockerとは？ Docker環境構築 Docker Hub 最後に 参考文献  Dockerとは？ メリット コマンドを数行打つだけで構築できる コードで環境やファイルの管理ができる どのパソコンでも同じ環境ができる（チーム開発で便利） Dockerデプロイ（Dockerの環境ごとデプロイ可能）  Docker環境構築 まず、ここをクリックしてDockerをインストールしましょう！Docker DesktopのDownload for Mac - Apple Chipをダウンロードします。その後、適宜アカウントの作成を行なって、サインインを行なってください。 docker run hello-world Hello from Docker!と表示されれば、インストールが無事にできています。 次に、デスクトップにMyDockerフォルダを作成します。 cd /Users/username/Desktop/MyDocker 今回はデスクトップにMyDockerフォルダを作成します。そこにDokerfileを作成します。 Vim Dockerfile 今回作成したDockerfileは、Dockerのイメージを自動で作成してくれるファイルです。 docker build . と入力するだけで、 Dockerシステムは Dockerfileを自動で読み込み、書かれている内容の通りの Dockerイメージを作成してくれます。冒頭でも述べましたが、普通アプリケーションの開発環境を整える際は、OS 内のコマンドで必要なソフト、例えば Apache や git、 Vim などをインストールすると思いますが、Dockerfileを使うとそうした一連の作業を自動で行うことが可能になります。その結果、開発環境の構築にかかる時間を大幅に短縮化し、 誰が行なっても同じ開発環境を作ることができるようになります。そして各ソフトウェアのバージョン相違等の環境ミスも無くせる！というメリットがあるという訳です。 Dockerfile ↓ Docker IMAGE ↓ コンテナ作成・Docker Hubへの公開・AWSで使用・イメージの改善 ここには、DockerコンテナにLinuxのubuntuを立てて、そのubuntu上にAnacondaをインストールする記述がされています。先ほど作成したDockerfileに書き込みましょう。Vimへの書き込み方は過去の私の記事:step3に書いてあります。 FROM ubuntu:latest RUN apt-get update && apt-get install -y sudo wget vim curl gawk make gcc RUN wget https://repo.continuum.io/archive/Anaconda3-2019.03-Linux-x86_64.sh && \ sh Anaconda3-2019.03-Linux-x86_64.sh -b && \ rm -f Anaconda3-2019.03-Linux-x86_64.sh && \ sudo curl -sL https://deb.nodesource.com/setup_10.x | sudo bash - && \ sudo apt-get install -y nodejs ENV PATH $PATH:/root/anaconda3/bin RUN pip install --upgrade pip RUN pip install pandas_datareader RUN pip install mplfinance RUN wget --quiet http://prdownloads.sourceforge.net/ta-lib/ta-lib-0.4.0-src.tar.gz -O ta-lib-0.4.0-src.tar.gz && \ tar xvf ta-lib-0.4.0-src.tar.gz && \ cd ta-lib/ && \ ./configure --prefix=/usr && \ make && \ sudo make install && \ cd .. && \ pip install TA-Lib && \ rm -R ta-lib ta-lib-0.4.0-src.tar.gz RUN mkdir /workspace CMD ["jupyter-lab", "--ip=0.0.0.0","--port=8888" ,"--no-browser", "--allow-root", "--LabApp.token=''"] Buildします（M1 Macには--platform linux/amd64が必要です）。 docker build --platform linux/amd64 . -t machinelearning:latest 「Successfully built」と表示されたら完了です。 下記のコマンドで確認しましょう！作成した名前がREPOSITORYに記載されていれば成功です(初めて作成する場合は時間がかかります)。 docker images 次にコンテナを作成します。作成した名前をREPOSITORYから見つけて、そこに記載されているIMAGE IDをコピーして以下のコードのIMAGE IDに記入してください。ここ（MyDocker:/workspace）の部分でMyDockerからworkspaceへマウントしています(usernameとIMAGE IDを変更することを忘れないでください)。 docker run -p 8888:8888 -v /Users/username/Desktop/MyDocker:/workspace --name machinelearning IMAGE ID 起動中のコンテナ一覧を確認しましょう。 docker ps docker ps -a # 起動してる・していないコンテナ全て表示 起動しているDockerのコンテナ操作するコマンド # 起動しているコンテナを止める docker stop machinelearning # Dockerfileを持っているディレクトリ上でこのコマンドを打つことでDocker imageを始めることができます docker start machinelearning 以下を打つことでいつでもjupyter labに入ることができる。 http://localhost:8888/ 以下のコマンドでコンテナ内に入ることができます。コンテナの中に入ることで新たにパッケージのインストールができます。 docker exec -it machinelearning bash tensorflowのインストールを行います。 pip install tensorflow exitでコンテナから出られます。 exit コンテナの削除方法（dockerfileさえあれば作成し放題・捨て放題） docker rm CONTAINER ID # docker containerの削除 docker rmi IMAGE ID　# docker imageの削除 コンテナとPC上にあるファイルのコピーの操作 コンテナにあるファイルを、自分のパソコンにコピーする方法 docker cp machinelearning:/workspace/test1.ipynb C:¥¥Users¥¥username¥¥Desktop¥¥MyDocker 自分のパソコンにあるファイルを、コンテナ内にコピーする方法 docker cp C:¥¥Users¥¥username¥¥Desktop¥¥MyDocker¥¥test3.ipynb machinelearning:/workspace/ コンテナ内のディレクトリにあるファイルのすべてを、自分のパソコンにコピーする方法 docker cp machinelearning:/workspace/. C:¥¥Users¥¥username¥¥Desktop¥¥MyDocker¥¥ 自分のパソコンにあるすべてのファイルを、コンテナ内のディレクトリにコピーする方法 docker cp C:¥¥Users¥¥username¥¥Desktop¥¥MyDocker¥¥. machinelearning:/workspace/ macの場合、マウントしているのでコンテナで作ったファイルは、自分のパソコンでも見たり操作することができるし、自分のパソコンで作ったファイルは、コンテナ内にも反映されます。  Docker Hub せっかくなのでDocker Hubを使用しましょう！Docker HubではこのようにDockerイメージを入手できます（欲しい環境（今回の例はmysql）を検索して手に入れます）。今回は自分でDockerfileを作成して使いましたが、自分の欲しいファイルがあればそれを使用しましょう！ Docker imageからコンテナを簡単にBuildできます。  最後に 今回は入門編として、Dockerのアカウント作成からDockerコンテナの作成とjupyter labに入るところまで行いました！今回作成したDockerは次回の記事で使用するので、ぜひそちらも合わせて見てみてください！いつか、Docker composeやAWS上にDockerを構築する！とかを記事にまとめたいですね。Dockerって便利ですよね！初めはその全体像がよくわからないと思います（私もわからなかったので避けていた時期がありました(T ^ T)）。私の場合は、全体像のイメージ図を自分で書いたり、後述の参考文献を読んだりして理解しました！Dockerは便利なので、これからガンガン使用して行きましょう！  参考文献 参考にさせて頂きました。大変勉強になります。ありがとうございます(T ^ T) さわって学ぶクラウドインフラ　docker基礎からのコンテナ構築 Docker環境構築入門 Dockerfileの書き方と使い方 docker コマンド Pythonのデータ分析の環境構築

最近インフラ周りの勉強を始めたのでdocekr+laravelの環境をEC2上に実現したいと思い奮闘しています。 参考になった記事を貼っていきます。 記事 【AWS 入門】EC2とDockerでHello Worldしよう 【シンプル解説】docker-composeを使ってLaravel,nginx,MySQL環境構築する https://simablog.net/docker-laravel-nginx-mysql/ SSH接続後 phpをインストールする https://qiita.com/nagahama/items/2fdc820791bee5d564ca composer　install https://qiita.com/kawanet/items/30c1acd4bc90ee0e535d composer installの際のエラー(/usr/local/bin/docker-compose: line 1: Not: command not found) https://github.com/docker/compose/issues/6268 amazon linux内でcomposerのpathを通す(どこでもcomposerコマンドを使えるようにする) https://qiita.com/miriwo/items/b25f9d4d74b7103f6ff6

経緯 APIを c#で作成したいと思い立ち、フレームワークである.Net Coreを使用しAPI開発をしようと思ったのがやり始めたきっかけです。 現在、.Net Coreで開発しようとしていて、Dockerの開発環境を作成したいと考えている方の参考になればと思っています。 はじめに 今回の記事では、 .Net Coreの開発環境をDockerfileを記述し作成する。 リアルタイムでコードの変更が反映されるようにする。 Dbコンテナも作成し、接続する。 apiを叩いて動作確認。 おまけ. マルチステージビルドで軽量化イメージを作成する。 という流れで解説します。 Dockerfileの作成 今回は、便宜上ファイル名をDockerfile.developとさせていただきます。 また、自分のプロジェクト名はapiMyAppです。 FROM mcr.microsoft.com/dotnet/sdk:5.0 WORKDIR /src COPY apiMyApp.csproj ./ RUN dotnet restore COPY . . RUN dotnet dev-certs https --clean && dotnet dev-certs https -t docker-compose.ymlの作成 docker-compose.ymlファイルを作成します。 docker-compose.yml version: '3.8' services: app: container_name: net-app build: context: . dockerfile: Dockerfile.develop ports: - 5000:5000 - 5001:5001 networks: - net-net depends_on: - db volumes: - .:/src command: dotnet watch run db: container_name: net-db platform: linux/x86_64 image: mysql:5.7 ports: - 3306:3306 environment: MYSQL_ROOT_PASSWORD: root MYSQL_DATABASE: mysql MYSQL_USER: user MYSQL_PASSWORD: secret command: mysqld --character-set-server=utf8 --collation-server=utf8_unicode_ci volumes: - ./mysql/data:/var/lib/mysql - ./mysql/init:/docker-entrypoint-initdb.d - ./mysql/my.cnf:/etc/mysql/conf.d/my.cnf networks: - net-net networks: net-net: driver: bridge .Net Coreのコンテナ名をnet-app、Databaseのコンテナ名をnet-dbと今回は設定しています。 ここで、ホットリロードの設定を行っているのが、net-appコンテナ内の docker-compose.yml volumes: - .:/src command: dotnet watch run の部分です。 volumesで、ローカルのコードと、コンテナ内のコードを同期させる。 commandsで、コンテナが立ち上がった際にホットリロードできるコマンドをうつ。 この二つ書いておけば、ホットリロードされます。 DBコンテナも記述していますが、おのおのコード内で接続できるよう記述してみてください。 詳しくは記述しませんが、.Net CorからDbコンテナに繋げる際、苦労した点としては、serverの部分がlocalhostでなくコンテナ名　を記述してやらないと繋がらなかったところです。(ここら辺はよくわかってない。) 後日更新予定