$ docker run --name mysql -e MYSQL_ROOT_PASSWORD=mysql -d -p 3306:3306 mysql Unable to find image 'mysql:latest' locally latest: Pulling from library/mysql docker: no matching manifest for linux/arm64/v8 in the manifest list entries. See 'docker run --help'. 普通に docker run しようとすると、no matching manifest が発生してしまうので、その時は --platform linux/x86_64 を指定する。 docker run -d --platform linux/x86_64 --name mysql -e MYSQL_ROOT_PASSWORD=mysql -p 3306:3306 mysql この記事によると、別のCPUアーキテクチャのエミュレーションをしているので動いているらしい。

jupyter/datascience-notebookなど、JupyterをDockerで使える(Jupyter Docker Stacks)についてまとめてみます。 このdockerイメージは、例えば普段使っているPCはWindowsやMacだけど、Linuxでしか動かないモジュールを使いたい人や、データ分析のタスクで、本番環境と開発環境を同じにしつつJupyterで開発したい人などはよく使っていると思います。ただこのdockerイメージは少し癖が強くデフォルトの状態で起動するとapt-getすらできないとか使い方がよくわからない部分があると思います。そこでこの記事で個人的にTipsをまとめてみました。 また私が使っているDocker + VSCode + Remote Containerのリポジトリもアップします。 SolKul/vscode-jupyter-container2 既にJupyteのDocker(Jupyter Docker Stacks)についての記事やサイトは山程出ています。まずそれらについてまとめ、そこにかかれていない私が役に立つと思うポイントをその後にまとめようと思います。 JupyterのDockerについての過去の記事や参考サイト Dockerで基本的なData Science環境(Jupyter, Python, R, Julia, 定番ライブラリ)を構築する。 この記事でパスワードの設定や、ポートフォワーディング、ボリュームの共有など基本的なことはすべて抑えられると思います。ただ、この記事はコンテナの起動をコマンドラインで行っています。dockerの知識がないうちはこれでdockerに慣れるのもいいですが、毎回この長いコマンドを打つのも大変です。慣れてきたらDockerfile+docker-composeを使ったほうが効率的です。 Docker + VSCode + Remote Containerで作る快適Jupyter Lab(Python)分析環境 この記事はVS CodeのRemote Containerでコンテナを動かしています。VS Codeであればファイルの配置もグラフィカルに表示され楽ですし、ファイルの中身もテキストエディタで編集できます。docker-composeも使っているので毎回コマンドを打つ必要がないです。何よりもVS Codeの強力なデバック機能や拡張機能が使えるのは魅力的です。 Jupyter Docker Stacksについてメモ 以下、Jupyter Docker Stacksを使う際のTipsをまとめます。 docker runよりdocker-composeを使う dockerに慣れてきたらdocker-composeを使うほうが断然楽です。次のdocker runコマンドと、その下のdocker-compose.ymlは同じ働きをします。 docker run \ --user root \ -e GRANT_SUDO=yes \ -e TZ=Asia/Tokyo \ -p 8888:8888 \ --name notebook \ -v ./work:/home/jovyan/work \ start-notebook.sh \ --NotebookApp.password='sha1:YOUR_PASSWORD_HASH_VALUE' docker-compose.yml version: '3' services: notebook: image: jupyter/datascience-notebook user: root ports: - '8888:8888' environment: - GRANT_SUDO=yes - TZ=Asia/Tokyo volumes: - ./work:/home/jovyan/work command: NotebookApp.password='sha1:YOUR_PASSWORD_HASH_VALUE' コマンドだと間違ってEnterを押してしまった時点で起動してしまいますが、docker-compose.ymlであれば落ち着いて編集し、最後に立ち上げる場合はdocker-compose upとすればいいだけです。またdocker-composeはVS CodeのRemote Containerでも使えます。 docker runのどのオプションがdocker-compose.ymlのどの項目に対応しているかなどは 複数のDockerコンテナを自動で立ち上げる構成管理ツール「Docker Compose」（Dockerの最新機能を使ってみよう：第7回） などを参照してください。 また、.envファイルを追加し、docker-compose.ymlを適切に書き換えればプロキシ下などでも使えます。詳しくはdocker-composeでのプロキシ設定を一つのファイルにまとめるを参考にしてください。 VSCode+Remote Containerで使う さらに言えば、VSCode+Remote Containerで使えば更に快適になります。上で述べたように、VSCodeであれば使うファイルの配置もグラフィカルに表示されるので、例えば、分析対象のデータを配置するときもわかりやすいです。ファイルの中身もテキストエディタで編集できます。ポートフォワーディングも後からできます。docker-compose.ymlも使っているので毎回コマンドを打つ必要がないです。何よりもVSCodeの強力なデバック機能や拡張機能が使えるのは魅力的です。なんならipynbファイルもそのまま開けます。 私がVSCode+Remote Containerで使う場合のリポジトリ、SolKul/vscode-jupyter-container2のファイル構造と各ファイルは次のようになります。 / 　├ .devcontainer/ │ ├ .env │ ├ devcontainer.json │ ├ docker-compose.yml │ └ Dockerfile 　└ work/ ※1 docker-compose.yml version: '3.3' services: jupyter-minimal: ※2 build: . #ビルド対象のDockerfileが同じフォルダ内にあるためピリオド(.)を打つ environment: # - JUPYTER_ENABLE_LAB=yes - GRANT_SUDO=yes working_dir: /home/jovyan/work user: root volumes: # ホストとのボリューム共有。../workは上のフォルダ構造で示した※1の一つ上の階層のworkフォルダを指し示す。 - ../work:/home/jovyan/work ポートフォワーディング下のようにVSCode上で後からできるのdocker-compose.ymlにはポートフォワーディングの設定は書いてません。 devcontainer.json { "name": "jupyter-devcontainer-project", "dockerComposeFile": [ "./docker-compose.yml" ], "service": "jupyter-minimal",//ここのサービス名は上のdocker-compose.ymlで示した※2のサービス名と一致させる "extensions": [ "ms-python.python" ], "workspaceFolder": "/home/jovyan/work" } Dockerfile FROM jupyter/minimal-notebook # RUN echo "c.NotebookApp.password='sha1:... としたほうがセキュリティ的に安全 RUN echo "c.NotebookApp.token=''" >> ~/.jupyter/jupyter_notebook_config.py RUN conda install -y jupyter_contrib_nbextensions VSCode+Remote Containerの詳しい使い方については「VSCode Remote Container」と検索するか、公式リファレンス(英語)を参考にしてください bashを起動したい場合 新しいモジュールをインストールしたり、ファイル操作やapt-getなどbashを操作したい場合があると思います。その場合はdocker psでコンテナIDを調べ、 docker exec -it コンテナID /bin/bash などすれば、bashを起動できます。またはVScodeでRemote containerしている場合は新しくターミナルを開けばいいです。 docker psやdocker execなどのコマンドがわからない場合は Docker ハンズオン - 基本コマンド編 などを参照してください。 ただ、デフォルトで使っている場合、ユーザーはjovyanになり、権限がないのでapt-get updateやapt-get installはできないです。これについては後述します。 デフォルトコマンドについて jupyter/datascience-notebookなど Jupyter Docker StacksのDockerコンテナは立ち上がると同時にデフォルトでstart-notebook.shが走り、各種設定を行います。(GRAT_SUDOの有効化など)。start-notebook.shが必要な設定を行うのでデフォルトコマンドは変更しないほうがいいです。 Jupyter Labについて 徐々に推奨エディタがJupyter Labに移り変わっていると思われます。 loacalhost:8888/treeにアクセスすると、従来のjupyter notebookに、loacalhost:8888/labにアクセスすると、jupyter labにアクセスします。ただ、環境変数JUPYTER_ENABLE_LABにyesを指定、つまり docker-compose.yml environment: - JUPYTER_ENABLE_LAB=yes とすると、localhost:8888にアクセスした時点でjupyter labにアクセスするするようになります。 nbextensionsについて 様々な拡張機能があるjupyter_contrib_nbextensionsはjupyter notebookでしか使えません。私は選択中の文字列について他の場所の同じ文字列も強調するHighlit Selected Wordを使いたいため、jupyter notebook+nbextensionsを使い続けています。いまのところ同じ機能はjupyter labは対応していません。 しかも、先程のように環境変数JUPYTER_ENABLE_LABにyesを指定すると、jupyter notebookがjupyter lab管理下のものになってしまい、nbextensionsは使えなくなります。nbextensionsを使いたい場合は環境変数JUPYTER_ENABLE_LABはいじらないようにしてください。 ユーザーと権限について ユーザーは管理者であるrootと、jovyanがいます。jupyter notebookを管理者権限で実行するのはセキュリティ的にまずいので、jupyter notebookはjovyanで起動するようになっています。 デフォルトではユーザーはjovyanになります。なのでデフォルトの状態で docker exec -it コンテナID /bin/bash とbashを実行しても、ユーザーはjovyanとなり、権限がないのでapt-get updateやapt-get installはできません。 しかしDockerfile中で USER root もしくは、docker-compose.ymlで docker-compose.yml environment: - JUPYTER_ENABLE_LAB=yes とユーザーをrootに切り替えた場合、bashはrootで起動し、apt-getなどが使えるようになります。 この状態で、su jovyanでjovyanに切り替えることができますが、このjovyanでは/opt/conda/bin/のパスが通っていないため、pipコマンドやcondaコマンドが使えまえん。export PATH=$PATH:/opt/conda/binなどとして、環境変数のPATHに/opt/conda/bin/を加えれば、pipコマンドやcondaコマンドが使えるようになります。 またユーザーをrootに切り替え、bashはrootで起動するようにした上で、環境変数GRANT_SUDOにyesを指定、つまりdocker-compose.ymlで、 docker-compose.yml - GRANT_SUDO=yes としていれば、su jovyanとしjovyanに切り替えた後のjovyanはsudoが使えるようになり、sudo apt-getなどができます。 つまりGRANT_SUDO=yes かつUSER rootならjovyanはsudoを使えるということです。詳しくは、 を参照してください。 モジュールのインストールとユーザー権限について 使っていて、conda installやpip installはrootとjovyanどちらのユーザーで実行しても、Pythonのプログラミングには問題ないように感じます。 しかし唯一jupyter_contrib_nbextensionsのインストールはjovyanで行ったほうがいいです。 rootで root $ conda install -y jupyter_contrib_nbextensions としてしまうと、nbextensions関連のファイルがroot権限になってしまいます。jupyter上にnbextensionsのタブが現れはしますが、jupyter起動ユーザーがjovyanなため、その状態でどのエクステンションを有効にしても実際は権限の問題で裏の設定ファイルが書き換わらずに、F5で更新すると無効になってしまいます。 なので、jupyter_contrib_nbextensionsのインストールはDockerfile内jovyanユーザーで予めやっておいたほうがいいです。 RUN conda install -y jupyter_contrib_nbextensions 詳しくは jupyter notebookが使えるdockerにnbextensionsが導入できない を参照してくださいい。

jupyter/datascience-notebookなど、JupyterをDockerで使える(Jupyter Docker Stacks)についてまとめてみます。 このdockerイメージは、例えば普段使っているPCはWindowsやMacだけど、Linuxでしか動かないモジュールを使いたい人や、データ分析のタスクで、本番環境と開発環境を同じにしつつJupyterで開発したい人などはよく使っていると思います。ただこのdockerイメージは少し癖が強くデフォルトの状態で起動するとapt-getすらできないとか使い方がよくわからない部分があると思います。そこでこの記事で個人的にTipsをまとめてみました。 また私が使っているDocker + VSCode + Remote Containerのリポジトリもアップします。 SolKul/vscode-jupyter-container2 既にJupyteのDocker(Jupyter Docker Stacks)についての記事やサイトは山程出ています。まずそれらについてまとめ、そこにかかれていない私が役に立つと思うポイントをその後にまとめようと思います。 JupyterのDockerについての過去の記事や参考サイト Dockerで基本的なData Science環境(Jupyter, Python, R, Julia, 定番ライブラリ)を構築する。 この記事でパスワードの設定や、ポートフォワーディング、ボリュームの共有など基本的なことはすべて抑えられると思います。ただ、この記事はコンテナの起動をコマンドラインで行っています。dockerの知識がないうちはこれでdockerに慣れるのもいいですが、毎回この長いコマンドを打つのも大変です。慣れてきたらDockerfile+docker-composeを使ったほうが効率的です。 Docker + VSCode + Remote Containerで作る快適Jupyter Lab(Python)分析環境 この記事はVS CodeのRemote Containerでコンテナを動かしています。VS Codeであればファイルの配置もグラフィカルに表示され楽ですし、ファイルの中身もテキストエディタで編集できます。docker-composeも使っているので毎回コマンドを打つ必要がないです。何よりもVS Codeの強力なデバック機能や拡張機能が使えるのは魅力的です。 Jupyter Docker Stacksについてメモ 以下、Jupyter Docker Stacksを使う際のTipsをまとめます。 docker runよりdocker-composeを使う dockerに慣れてきたらdocker-composeを使うほうが断然楽です。次のdocker runコマンドと、その下のdocker-compose.ymlは同じ働きをします。 docker run \ --user root \ -e GRANT_SUDO=yes \ -e TZ=Asia/Tokyo \ -p 8888:8888 \ --name notebook \ -v ./work:/home/jovyan/work \ start-notebook.sh \ --NotebookApp.password='sha1:YOUR_PASSWORD_HASH_VALUE' docker-compose.yml version: '3' services: notebook: image: jupyter/datascience-notebook user: root ports: - '8888:8888' environment: - GRANT_SUDO=yes - TZ=Asia/Tokyo volumes: - ./work:/home/jovyan/work command: NotebookApp.password='sha1:YOUR_PASSWORD_HASH_VALUE' コマンドだと間違ってEnterを押してしまった時点で起動してしまいますが、docker-compose.ymlであれば落ち着いて編集し、最後に立ち上げる場合はdocker-compose upとすればいいだけです。またdocker-composeはVS CodeのRemote Containerでも使えます。 docker runのどのオプションがdocker-compose.ymlのどの項目に対応しているかなどは 複数のDockerコンテナを自動で立ち上げる構成管理ツール「Docker Compose」（Dockerの最新機能を使ってみよう：第7回） などを参照してください。 また、.envファイルを追加し、docker-compose.ymlを適切に書き換えればプロキシ下などでも使えます。詳しくはdocker-composeでのプロキシ設定を一つのファイルにまとめるを参考にしてください。 VSCode+Remote Containerで使う さらに言えば、VSCode+Remote Containerで使えば更に快適になります。上で述べたように、VSCodeであれば使うファイルの配置もグラフィカルに表示されるので、例えば、分析対象のデータを配置するときもわかりやすいです。ファイルの中身もテキストエディタで編集できます。ポートフォワーディングも後からできます。docker-compose.ymlも使っているので毎回コマンドを打つ必要がないです。何よりもVSCodeの強力なデバック機能や拡張機能が使えるのは魅力的です。なんならipynbファイルもそのまま開けます。 私がVSCode+Remote Containerで使う場合のリポジトリ、SolKul/vscode-jupyter-container2のファイル構造と各ファイルは次のようになります。 / 　├ .devcontainer/ │ ├ .env │ ├ devcontainer.json │ ├ docker-compose.yml │ └ Dockerfile 　└ work/ ※1 docker-compose.yml version: '3.3' services: jupyter-minimal: ※2 build: . #ビルド対象のDockerfileが同じフォルダ内にあるためピリオド(.)を打つ environment: # - JUPYTER_ENABLE_LAB=yes - GRANT_SUDO=yes working_dir: /home/jovyan/work user: root volumes: # ホストとのボリューム共有。../workは上のフォルダ構造で示した※1の一つ上の階層のworkフォルダを指し示す。 - ../work:/home/jovyan/work ポートフォワーディング下のようにVSCode上で後からできるのdocker-compose.ymlにはポートフォワーディングの設定は書いてません。 devcontainer.json { "name": "jupyter-devcontainer-project", "dockerComposeFile": [ "./docker-compose.yml" ], "service": "jupyter-minimal",//ここのサービス名は上のdocker-compose.ymlで示した※2のサービス名と一致させる "extensions": [ "ms-python.python" ], "workspaceFolder": "/home/jovyan/work" } Dockerfile FROM jupyter/minimal-notebook # RUN echo "c.NotebookApp.password='sha1:... としたほうがセキュリティ的に安全 RUN echo "c.NotebookApp.token=''" >> ~/.jupyter/jupyter_notebook_config.py RUN conda install -y jupyter_contrib_nbextensions VSCode+Remote Containerの詳しい使い方については「VSCode Remote Container」と検索するか、公式リファレンス(英語)を参考にしてください bashを起動したい場合 新しいモジュールをインストールしたり、ファイル操作やapt-getなどbashを操作したい場合があると思います。その場合はdocker psでコンテナIDを調べ、 docker exec -it コンテナID /bin/bash などすれば、bashを起動できます。またはVScodeでRemote containerしている場合は新しくターミナルを開けばいいです。 docker psやdocker execなどのコマンドがわからない場合は Docker ハンズオン - 基本コマンド編 などを参照してください。 ただ、デフォルトで使っている場合、ユーザーはjovyanになり、権限がないのでapt-get updateやapt-get installはできないです。これについては後述します。 デフォルトコマンドについて jupyter/datascience-notebookなど Jupyter Docker StacksのDockerコンテナは立ち上がると同時にデフォルトでstart-notebook.shが走り、各種設定を行います。(GRAT_SUDOの有効化など)。start-notebook.shが必要な設定を行うのでデフォルトコマンドは変更しないほうがいいです。 Jupyter Labについて 徐々に推奨エディタがJupyter Labに移り変わっていると思われます。 loacalhost:8888/treeにアクセスすると、従来のjupyter notebookに、loacalhost:8888/labにアクセスすると、jupyter labにアクセスします。ただ、環境変数JUPYTER_ENABLE_LABにyesを指定、つまり docker-compose.yml environment: - JUPYTER_ENABLE_LAB=yes とすると、localhost:8888にアクセスした時点でjupyter labにアクセスするするようになります。 nbextensionsについて 様々な拡張機能があるjupyter_contrib_nbextensionsはjupyter notebookでしか使えません。私は選択中の文字列について他の場所の同じ文字列も強調するHighlit Selected Wordを使いたいため、jupyter notebook+nbextensionsを使い続けています。いまのところ同じ機能はjupyter labは対応していません。 しかも、先程のように環境変数JUPYTER_ENABLE_LABにyesを指定すると、jupyter notebookがjupyter lab管理下のものになってしまい、nbextensionsは使えなくなります。nbextensionsを使いたい場合は環境変数JUPYTER_ENABLE_LABはいじらないようにしてください。 ユーザーと権限について ユーザーは管理者であるrootと、jovyanがいます。jupyter notebookを管理者権限で実行するのはセキュリティ的にまずいので、jupyter notebookはjovyanで起動するようになっています。 デフォルトではユーザーはjovyanになります。なのでデフォルトの状態で docker exec -it コンテナID /bin/bash とbashを実行しても、ユーザーはjovyanとなり、権限がないのでapt-get updateやapt-get installはできません。 しかしDockerfile中で USER root もしくは、docker-compose.ymlで docker-compose.yml environment: - JUPYTER_ENABLE_LAB=yes とユーザーをrootに切り替えた場合、bashはrootで起動し、apt-getなどが使えるようになります。 この状態で、su jovyanでjovyanに切り替えることができますが、このjovyanでは/opt/conda/bin/のパスが通っていないため、pipコマンドやcondaコマンドが使えまえん。export PATH=$PATH:/opt/conda/binなどとして、環境変数のPATHに/opt/conda/bin/を加えれば、pipコマンドやcondaコマンドが使えるようになります。 またユーザーをrootに切り替え、bashはrootで起動するようにした上で、環境変数GRANT_SUDOにyesを指定、つまりdocker-compose.ymlで、 docker-compose.yml - GRANT_SUDO=yes としていれば、su jovyanとしjovyanに切り替えた後のjovyanはsudoが使えるようになり、sudo apt-getなどができます。 つまりGRANT_SUDO=yes かつUSER rootならjovyanはsudoを使えるということです。詳しくは、 を参照してください。 モジュールのインストールとユーザー権限について 使っていて、conda installやpip installはrootとjovyanどちらのユーザーで実行しても、Pythonのプログラミングには問題ないように感じます。 しかし唯一jupyter_contrib_nbextensionsのインストールはjovyanで行ったほうがいいです。 rootで root $ conda install -y jupyter_contrib_nbextensions としてしまうと、nbextensions関連のファイルがroot権限になってしまいます。jupyter上にnbextensionsのタブが現れはしますが、jupyter起動ユーザーがjovyanなため、その状態でどのエクステンションを有効にしても実際は権限の問題で裏の設定ファイルが書き換わらずに、F5で更新すると無効になってしまいます。 なので、jupyter_contrib_nbextensionsのインストールはDockerfile内jovyanユーザーで予めやっておいたほうがいいです。 RUN conda install -y jupyter_contrib_nbextensions 詳しくは jupyter notebookが使えるdockerにnbextensionsが導入できない を参照してくださいい。

jupyter/scipy-notebookや、jupyter/datascience-notebookなど、JupyterをDockerで使える(Jupyter Docker Stacks)についてまとめてみます。 このdockerイメージは、例えば普段使っているPCはWindowsやMacだけど、Linuxでしか動かないモジュールを使いたい人や、データ分析のタスクで、本番環境と開発環境を同じにしつつJupyterで開発したい人などはよく使っていると思います。ただこのdockerイメージは少し癖が強くデフォルトの状態で起動するとapt-getすらできないとか使い方がよくわからない部分があると思います。そこでこの記事で個人的にTipsをまとめてみました。 また私が使っているDocker + VSCode + Remote Containerのリポジトリもアップします。 SolKul/vscode-jupyter-container2 既にJupyteのDocker(Jupyter Docker Stacks)についての記事やサイトは山程出ています。まずそれらについてまとめ、そこにかかれていない私が役に立つと思うポイントをその後にまとめようと思います。 JupyterのDockerについての過去の記事や参考サイト Dockerで基本的なData Science環境(Jupyter, Python, R, Julia, 定番ライブラリ)を構築する。 この記事でパスワードの設定や、ポートフォワーディング、ボリュームの共有など基本的なことはすべて抑えられると思います。ただ、この記事はコンテナの起動をコマンドラインで行っています。dockerの知識がないうちはこれでdockerに慣れるのもいいですが、毎回この長いコマンドを打つのも大変です。慣れてきたらDockerfile+docker-composeを使ったほうが効率的です。 Docker + VSCode + Remote Containerで作る快適Jupyter Lab(Python)分析環境 この記事はVS CodeのRemote Containerでコンテナを動かしています。VS Codeであればファイルの配置もグラフィカルに表示され楽ですし、ファイルの中身もテキストエディタで編集できます。docker-composeも使っているので毎回コマンドを打つ必要がないです。何よりもVS Codeの強力なデバック機能や拡張機能が使えるのは魅力的です。 Jupyter Docker Stacksについてメモ 以下、Jupyter Docker Stacksを使う際のTipsをまとめます。 docker runよりdocker-composeを使う dockerに慣れてきたらdocker-composeを使うほうが断然楽です。次のdocker runコマンドと、その下のdocker-compose.ymlは同じ働きをします。 docker run \ --user root \ -e GRANT_SUDO=yes \ -e TZ=Asia/Tokyo \ -p 8888:8888 \ --name notebook \ -v ./work:/home/jovyan/work \ start-notebook.sh \ --NotebookApp.password='sha1:YOUR_PASSWORD_HASH_VALUE' docker-compose.yml version: '3' services: notebook: image: jupyter/datascience-notebook user: root ports: - '8888:8888' environment: - GRANT_SUDO=yes - TZ=Asia/Tokyo volumes: - ./work:/home/jovyan/work command: start-notebook.sh --NotebookApp.password='sha1:YOUR_PASSWORD_HASH_VALUE' コマンドだと間違ってEnterを押してしまった時点で起動してしまいますが、docker-compose.ymlであれば落ち着いて編集し、最後に立ち上げる場合はdocker-compose upとすればいいだけです。またdocker-composeはVS CodeのRemote Containerでも使えます。 docker runのどのオプションがdocker-compose.ymlのどの項目に対応しているかなどは 複数のDockerコンテナを自動で立ち上げる構成管理ツール「Docker Compose」（Dockerの最新機能を使ってみよう：第7回） などを参照してください。 また、docker runコマンド-eオプションや、docker-compose.ymlのenvironmentでコンテナ中に環境変数を設定しています。 docker runの-eオプションについては公式リファレンスを参照してください。 run — Docker-docs-ja 19.03 ドキュメント docker-composeの環境変数についても公式リファレンスを参照するか、私が過去まとめた記事があるのでそちらを参照してください。 docker-composeのenv_fileと.envファイルの違い また、.envファイルを追加し、docker-compose.ymlを適切に書き換えればプロキシ下などでも使えます。詳しくはdocker-composeでのプロキシ設定を一つのファイルにまとめるを参考にしてください。 VSCode+Remote Containerで使う さらに言えば、VSCode+Remote Containerで使えば更に快適になります。上で述べたように、VSCodeであれば使うファイルの配置もグラフィカルに表示されるので、例えば、分析対象のデータを配置するときもわかりやすいです。ファイルの中身もテキストエディタで編集できます。ポートフォワーディングも後からできます。docker-compose.ymlも使っているので毎回コマンドを打つ必要がないです。何よりもVSCodeの強力なデバック機能や拡張機能が使えるのは魅力的です。なんならipynbファイルもそのまま開けます。 私がVSCode+Remote Containerで使う場合のリポジトリ、SolKul/vscode-jupyter-container2のファイル構造と各ファイルは次のようになります。 / 　├ .devcontainer/ │ ├ .env │ ├ devcontainer.json │ ├ docker-compose.yml │ └ Dockerfile 　└ work/ ※1 docker-compose.yml version: '3.3' services: jupyter-minimal: ※2 build: . #ビルド対象のDockerfileが同じフォルダ内にあるためピリオド(.)を打つ environment: # - JUPYTER_ENABLE_LAB=yes - GRANT_SUDO=yes working_dir: /home/jovyan/work user: root volumes: # ホストとのボリューム共有。../workは上のフォルダ構造で示した※1の一つ上の階層のworkフォルダを指し示す。 - ../work:/home/jovyan/work ポートフォワーディング下のようにVSCode上で後からできるのdocker-compose.ymlにはポートフォワーディングの設定は書いてません。 devcontainer.json { "name": "jupyter-devcontainer-project", "dockerComposeFile": [ "./docker-compose.yml" ], "service": "jupyter-minimal",//ここのサービス名は上のdocker-compose.ymlで示した※2のサービス名と一致させる "extensions": [ "ms-python.python" ], "workspaceFolder": "/home/jovyan/work" } Dockerfile FROM jupyter/minimal-notebook # RUN echo "c.NotebookApp.password='sha1:... としたほうがセキュリティ的に安全 RUN echo "c.NotebookApp.token=''" >> ~/.jupyter/jupyter_notebook_config.py RUN conda install -y jupyter_contrib_nbextensions VSCode+Remote Containerの詳しい使い方については「VSCode Remote Container」と検索するか、公式リファレンス(英語)を参考にしてください bashを起動したい場合 新しいモジュールをインストールしたり、ファイル操作やapt-getなどbashを操作したい場合があると思います。その場合はdocker psでコンテナIDを調べ、 docker exec -it コンテナID /bin/bash などすれば、bashを起動できます。またはVScodeでRemote containerしている場合は新しくターミナルを開けばいいです。 docker psやdocker execなどのコマンドがわからない場合は Docker ハンズオン - 基本コマンド編 などを参照してください。 ただ、デフォルトで使っている場合、ユーザーはjovyanになり、権限がないのでapt-get updateやapt-get installはできないです。これについては後述します。 デフォルトコマンドについて jupyter/datascience-notebookなど Jupyter Docker StacksのDockerコンテナは立ち上がると同時にデフォルトでstart-notebook.shが走り、各種設定を行います。(GRAT_SUDOの有効化など)。start-notebook.shが必要な設定を行うのでデフォルトコマンドは変更しないほうがいいです。 Jupyter Labについて 徐々に推奨エディタがJupyter Labに移り変わっていると思われます。 loacalhost:8888/treeにアクセスすると、従来のjupyter notebookに、loacalhost:8888/labにアクセスすると、jupyter labにアクセスします。ただ、環境変数JUPYTER_ENABLE_LABにyesを指定、つまり docker-compose.yml environment: - JUPYTER_ENABLE_LAB=yes とすると、localhost:8888にアクセスした時点でjupyter labにアクセスするするようになります。 nbextensionsについて 様々な拡張機能があるjupyter_contrib_nbextensionsはjupyter notebookでしか使えません。私は選択中の文字列について他の場所の同じ文字列も強調するHighlight Selected Wordを使いたいため、jupyter notebook+nbextensionsを使い続けています。いまのところ同じ機能はjupyter labは対応していません。 しかも、先程のように環境変数JUPYTER_ENABLE_LABにyesを指定すると、jupyter notebookがjupyter lab管理下のものになってしまい、nbextensionsは使えなくなります。nbextensionsを使いたい場合は環境変数JUPYTER_ENABLE_LABはいじらないようにしてください。 ユーザーと権限について ユーザーは管理者であるrootと、jupyter notebookを実行するjovyanがいます。jupyter notebookを管理者権限で実行するのはセキュリティ的にまずいので、jupyter notebookはjovyanで起動するようになっています。 デフォルトではユーザーはjovyanになります。なのでデフォルトの状態で docker exec -it コンテナID /bin/bash とbashを実行しても、ユーザーはjovyanとなり、権限がないのでapt-get updateやapt-get installはできません。 しかしDockerfile中で USER root もしくは、docker-compose.ymlで docker-compose.yml user: root とユーザーをrootに切り替えた場合、bashはrootで起動し、apt-getなどが使えるようになります。 この状態で、su jovyanでjovyanに切り替えることができますが、このjovyanでは/opt/conda/bin/のパスが通っていないため、pipコマンドやcondaコマンドが使えまえん。export PATH=$PATH:/opt/conda/binなどとして、環境変数のPATHに/opt/conda/bin/を加えれば、pipコマンドやcondaコマンドが使えるようになります。 またユーザーをrootに切り替え、bashはrootで起動するようにした上で、環境変数GRANT_SUDOにyesを指定、つまりdocker-compose.ymlで、 docker-compose.yml environment: - GRANT_SUDO=yes としていれば、su jovyanとしjovyanに切り替えた後のjovyanはsudoが使えるようになり、sudo apt-getなどができます。 つまりGRANT_SUDO=yes かつUSER rootならjovyanはsudoを使えるということです。詳しくは、 を参照してください。 モジュールのインストールとユーザー権限について rootでconda installなどでモジュールを管理者権限でインストールしてしまうと、jupyter notebookを実行するjovyanユーザーで不具合が起きるように思えますが、使っていて、conda installやpip installなどモジュールのインストールをrootとjovyanどちらのユーザーで実行しても、ほぼほぼ、Pythonのプログラミングには問題ないように感じます。 しかしjupyter_contrib_nbextensionsのインストールはjovyanで行ったほうがいいです。 rootで root $ conda install -y jupyter_contrib_nbextensions としてしまうと、nbextensions関連のファイルがroot権限になってしまいます。jupyter上にnbextensionsのタブが現れはしますが、jupyter起動ユーザーがjovyanなため、その状態でどのエクステンションを有効にしても実際は権限の問題で裏の設定ファイルが書き換わらずに、F5で更新すると無効になってしまいます。 なので、jupyter_contrib_nbextensionsのインストールはDockerfile内jovyanユーザーで予めやっておいたほうがいいです。 RUN conda install -y jupyter_contrib_nbextensions 詳しくは jupyter notebookが使えるdockerにnbextensionsが導入できない を参照してくださいい。

API 開発を Lambda と API Gateway の組み合わせで開発することが多くなってきました。 しかし、AWS のサービスはコンソールからポチポチと設定できてしまうので保守・運用する側からは設定情報が Git などに残らずに困ってしまいます。 そこでこれらの環境を Git で管理できるようにすべくソースコードで環境を構築してしまうチュートリアルを用意しました。 概要 AWS Lambda と Amazon API Gateway を本番環境で利用するときの Docker 開発環境です。 ここでは API 定義に Swagger を利用しています。 目次 環境構成 　・前提条件 　・開発環境で作成するファイル 　・AWS 上に作成されるリソース 開発環境作成手順 　・フォルダ構成 　・AWS SAM CLI 用 の Python ベースの dockerfile 作成 　・docker-compose.yml の作成 　・swagger.yml の作成 　・docker-compose の起動 　・AWS SAM CLI を使った Lambda 関数の作成 　　　・コンテナへのアタッチ 　　　・AWS SAM CLI の実行と初期プロジェクトの作成 　・template.yaml の実装 　・ソースコードの実装 　・S3 バケットの作成 　・swagger.yml を S3 へアップロード 本番デプロイ準備 　・samconfig.toml の作成 　・ビルド 本番デプロイ 　・作成されたリソースの確認 いざコード開発の開始！！ 削除コマンド 最後に 環境構成 作成するファイルや実際に AWS 上に作成されるリソースです。 前提条件 著者は Mac 環境で動作検証を行っております。 Docker を利用するのでインストールしておいてください。 ホストサーバーに ~/.aws フォルダと config ファイルにcredential や profile 情報が設定されていることを前提で進めます。 まだ、設定していない方は AWS CLI のインストールと AWS CLI の設定方法を参考にしてください。 開発環境で作成するファイル AWS SAM CLI と node.js のビルド環境を動かす Python用の Dockerfile API Gateway と Lambda の環境を構築する template.yaml API Gateway の API エンドポイントなどを定義する swagger.yml SAM のビルド & デプロイ用の設定ファイル samconfig.toml Node.js のパッケージ管理ファイル package.json AWS SAM CLI と Swagger Editor のコンテナを起動する docker-compose.yml lambda で実行されるソースコード一式 ※ 開発環境と言っても、今回ご紹介する手順は最終的に AWS 上へデプロイする形になります。 AWS SAM では lambda をローカルでエミュレートできるみたいですが今回は試していません。 AWS 上に作成されるリソース Swagger の swagger.yml ファイル と SAM の template.yaml を保存する S3 バケット （手動作成） API Gateway SAM から自動生成される Lambda 用の IAM Role Lambda (nodejs14) 開発環境作成手順 では、開発環境を作成していきます。 フォルダ構成 下記が作成するフォルダ構成です。 Project │── Dockerfiles │ └── python │ └── Dockerfile ├── README.md ├── docker-compose.yml ├── sam-app │ ├── README.md │ ├── events │ ├── hello-world │ │ ├── app.js │ │ ├── node_modules │ │ ├── package.json │ │ ├── tests │ ├── samconfig.toml │ └── template.yaml └── swagger.yml Dockerfiles:　利用するコンテナを定義した dockerfile 群 sam-app:　AWS SAM CLI で作成される初期ソースコードのテンプレート docker-compose.yml:　Dockerfiles で定義したコンテナを管理 & 実行 swagger.yml:　Swagger で定義した OPEN API 設計ファイル AWS SAM CLI 用 の Python ベースの dockerfile 作成 AWS SAM CLI を実行する Dockerfile を作成します。ついでに node.js をビルドする npm も Python コンテナにインストールしてしまいます。ここは node コンテナと分けてもらっても構わないですが、特に Web サーバとして動かす必要がないので、 Python コンテナに npm を同居させています。 Dockerfiles/python/Dockerfile FROM python:3.9-alpine ENV NODE_PATH /usr/lib/node_modules/ # install nodejs RUN apk update \ && apk add --no-cache \ nodejs \ npm \ gcc \ libc-dev \ git # install aws-cli RUN pip3 install awscli # install aws-sam-cli RUN pip3 install -U aws-sam-cli # change work directory RUN mkdir -p /app WORKDIR /app docker-compose.yml の作成 docker-compose.yml です。先ほど作成した AWS SAM CLI 用の Dockerfile と Swagger Editor をローカルで動かすコンテナを実行します。 docker-compose.yml version: "3.5" services: sam: build: context: ./dockerfiles/python/ dockerfile: Dockerfile tty: true # 後でコンテナ内にアタッチするので tty と stdin_open を true にする stdin_open: true image: sam working_dir: /app volumes: - .:/app # ホストのプロジェクトフォルダをコンテナ内の /app にマウント - ~/.aws:/root/.aws # aws cli をコンテナから操作できるようにホストの .aws をマウント container_name: sam swagger: ports: - "8081:8080" image: swaggerapi/swagger-editor working_dir: /app environment: # コンテナ内の swagger 定義ファイルパス - SWAGGER_FILE=/app/swagger.yml volumes: - .:/app - ~/.aws:/root/.aws container_name: swagger swagger.yml の作成 swagger.yml に API 定義を記述していきます。今回はサンプルとして、Swagger 公式が上げている OpenAPI 3.0 の petstore を参考に AWS API Gateway に対応させるように改造していきます。 今回サンプル用に改造した yaml ファイルが下記になります。 swagger.yml openapi: "3.0.0" info: version: 1.0.0 title: Swagger Petstore license: name: MIT servers: - url: http://petstore.swagger.io/v1 paths: /pets: get: summary: List all pets operationId: listPets tags: - pets parameters: - name: limit in: query description: How many items to return at one time (max 100) required: false schema: type: integer format: int32 responses: '200': description: A paged array of pets headers: x-next: description: A link to the next page of responses schema: type: string content: application/json: schema: $ref: "#/components/schemas/Pets" default: description: unexpected error content: application/json: schema: $ref: "#/components/schemas/Error" x-amazon-apigateway-integration: uri: # APIからキックするLambda関数のARN Fn::Sub: arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${PetStoreFunction.Arn}/invocations passthroughBehavior: when_no_templates httpMethod: GET type: aws_proxy post: summary: Create a pet operationId: createPets tags: - pets responses: '201': description: Null response default: description: unexpected error content: application/json: schema: $ref: "#/components/schemas/Error" x-amazon-apigateway-integration: uri: # APIからキックするLambda関数のARN Fn::Sub: arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${PetStoreFunction.Arn}/invocations passthroughBehavior: when_no_templates httpMethod: POST type: aws_proxy ########### 以下省略 ########### components: ########### 以下省略 ########### 追加した箇所は、下記2箇所です。 x-amazon-apigateway-integration: uri: # APIからキックするLambda関数のARN Fn::Sub: arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${PetStoreFunction.Arn}/invocations passthroughBehavior: when_no_templates httpMethod: POST ## POST のエンドポイントは GET を指定する type: aws_proxy x-amazon-apigateway-integration: uri: # APIからキックするLambda関数のARN Fn::Sub: arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${PetStoreFunction.Arn}/invocations passthroughBehavior: when_no_templates httpMethod: GET ## GET のエンドポイントは GET を指定する type: aws_proxy 他はすべて、参考にした github のコードのままになります。 ここでは、API Gateway がキックする Lambda を定義しています。 Swagger で定義した API Gateway のエンドポイントパスを叩くと、ここで定義した lambda が実行されるといった処理になります。 x-amazon-apigateway-integration に定義する httpMethod は swagger で定義したエンドポイントパスに対応するメソッドを指定してください。 また uri には後述する Lambda 関数の ARN を指定します。したがって ${PetStoreFunction.Arn} は、ご自身の環境の Lambda 関数名.arnを指定してください docker-compose の起動 ここで一度 docker-compose up で Docker コンテナを起動してみます。 起動が完了したら localhost:8081 にアクセスしてみます。 下記のように Swagger Editor が表示されたら OK です。 ブラウザの Swagger Editor で修正した yaml ファイルはローカルには自動で反映されないので、必ずローカルのIDE または エディタから編集してブラウザで確認といった形で修正内容を確認しましょう。 もしブラウザで修正したい場合は yaml ファイルをブラウザで修正後ダウンロードもできます。 AWS SAM CLI を使った Lambda 関数の作成 続いて、立ち上げた AWS SAM CLI 用のコンテナ（コンテナ名: sam）にアクセスして AWS SAM CLI を実行し初期プロジェクトを作成します。 コンテナへのアタッチ ▼ コマンドの方は下記コマンドを実行します。 ホスト $ docker exec -it sam /bin/sh ▼ VSCodeの場合は Docker Extension からコンテナ内へアタッチすることができます。 AWS SAM CLI の実行と初期プロジェクトの作成 アタッチしたコンテナ内で AWS SAM CLI を実行して初期プロジェクトを作成します。 AWS SAM CLI の AWS 公式チュートリアルを参考にしています。 ▼ 実行した SAM CLI のコマンド（選択した選択肢のみ記載しています） samコンテナ /app $ sam --version # SAM CLI, version 1.18.1 /app $ sam init Which template source would you like to use? 1 - AWS Quick Start Templates What package type would you like to use? 1 - Zip (artifact is a zip uploaded to S3) Which runtime would you like to use? 1 - nodejs14.x AWS quick start application templates: 1 - Hello World Example # 出力結果 ----------------------- Generating application: ----------------------- Name: sam-app Runtime: nodejs14.x Dependency Manager: npm Application Template: hello-world Output Directory: . Next steps can be found in the README file at ./sam-app/README.md 上記のようにテンプレートを作成するための選択肢が出てきます。 今回は nodejs で lambda を開発するので Runtime は nodejs14.x を選びました。 デプロイ先は S３ にしております。 その他の選択肢は上記を参考にしてください。 テンプレートが作成されるとプロジェクトフォルダに hello-world フォルダが作成されます。 template.yaml の実装 ここでは、チュートリアルで作成された template.yaml を編集し swagger に対応させるように修正します。 追記する観点は下記２項目です。 API Gateway の定義を追加 Lambda function にエンドポイントパスイベントを定義 ※ 上記２点の修正箇所に伴って Outputs の値なども修正しております。 template.yaml AWSTemplateFormatVersion: '2010-09-09' Transform: AWS::Serverless-2016-10-31 Description: > sam-app Sample SAM Template for sam-app Globals: Function: Timeout: 3 Parameters: # swagger.yml をアップロードしているバケット名 BucketName: Type: String Resources: # PetStore 用の API Gateway を定義 PetStoreApi: Type: AWS::Serverless::Api Properties: Name: !Ref "AWS::StackName" StageName: prod OpenApiVersion: 3.0.0 DefinitionBody: Fn::Transform: Name: AWS::Include Parameters: Location: !Sub s3://${BucketName}/swagger.yml # Lambda 関数の設定を定義 (Hello-world のコードを流用) PetStoreFunction: Type: AWS::Serverless::Function Properties: CodeUri: hello-world/ Handler: app.lambdaHandler Runtime: nodejs14.x Events: PetsGet: Type: Api Properties: Path: /pets Method: get RestApiId: !Ref PetStoreApi # API を参照 PetsPetIdGet: Type: Api Properties: Path: /pets/{petId} Method: get RestApiId: !Ref PetStoreApi # API を参照 PetsPost: Type: Api Properties: Path: /pets Method: post RestApiId: !Ref PetStoreApi # API を参照 Outputs: PetStoreApi: Description: "API Gateway endpoint URL for Prod stage for Hello World function" Value: !Sub "https://${PetStoreApi}.execute-api.${AWS::Region}.amazonaws.com/Prod/pet/" PetStoreFunction: Description: "Hello World Lambda Function ARN" Value: !GetAtt PetStoreFunction.Arn PetStoreFunctionIamRole: Description: "Implicit IAM Role created for Hello World function" Value: !GetAtt PetStoreFunctionRole.Arn 注目するところは下記設定です。 PetStoreApi に OpenApiVersion: 3.0.0 を指定する。 PetStoreApi の DefinitionBody に swagger.yml をアップロードした S3 バケット URL をセットする。 OpenApiVersion: 3.0.0 DefinitionBody: Fn::Transform: Name: AWS::Include Parameters: Location: !Sub s3://${BucketName}/swagger.yml PetStoreFunction の Events に swagger.yml で定義したエンドポイントパスを定義する。 Events: PetsGet: Type: Api Properties: Path: /pets Method: get RestApiId: !Ref PetStoreApi # API を参照 ソースコードの実装 Lambda Function のソースコードを実装します。 ここでは、サンプルのためチュートリアルのコードのままにします。 S3 バケットの作成 ビルドされた template.yaml やコード、 swagger.yml を保存する S3 バケットを手動で作成します。 samコンテナ /app $ aws s3 mb s3://sam-app-bucket-pfr379vgrp0 --profile default swagger.yml を S3 へアップロード 先ほど作成した S3 バケットに swagger.yml ファイルをアップロードします。 samコンテナ /app $ aws s3 cp swagger.yml s3://sam-app-bucket-pfr379vgrp0/swagger.yml --profile default 以上が開発環境の作成です。次に AWS 環境へデプロイする準備を行います。 本番デプロイ準備 本番へデプロイするための準備を行います。 samconfig.toml の作成 デプロイするための情報を toml 形式で sam-app 直下に保存します。 sam-app/samconfig.toml version=0.1 [default.deploy.parameters] stack_name = "sam-app" s3_bucket = "sam-app-bucket-pfr379vgrp0" s3_prefix = "sam-app" region = "ap-northeast-1" confirm_changeset = true capabilities = "CAPABILITY_IAM" ビルド AWS SAM CLI を利用してコードのビルドを行います。 samコンテナ /app $ cd sam-app /app/sam-app $ sam build ビルドが完了し、.aws-sam フォルダに build フォルダが作成されていればビルドが成功です。 ちなみに自動で npm install コマンドが実行され node_module をビルドに含めてくれているみたいです。 本番デプロイ 最後にデプロイを行います。 samコンテナ /app/sam-app $ sam deploy --profile default --config-env default --parameter-overrides BucketName=sam-app-bucket-pfr379vgrp0 ### 省略 ### Previewing CloudFormation changeset before deployment ====================================================== Deploy this changeset? [y/N]: y 2021-04-14 08:23:23 - Waiting for stack create/update to complete CloudFormation events from changeset ### 省略 ### Successfully created/updated stack - sam-app in ap-northeast-1 オプション 解説 --profile AWS CLI の ~/.aws/config に設定した profile。自身のデプロイ先のAWSアカウントを指定してください。 デフォルト: default --config-env samconig.toml の設定情報 deploy.parameters の前の文字列を指定します。 デフォルト: default ---parameter-overrides template.yaml の Parameters に定義したパラメータをここで指定できます。 Successfully が表示されたらデプロイの完了です。 作成されたリソースの確認 ▼ API Gateway のリソースとステージ ▼ Swagger で定義したモデルの確認 いざコード開発の開始！！ これで環境構築と、デプロイができました！！ あとは、Lambda Function の開発を行い、コードを修正したら上記手順でまたビルド & デプロイ すると AWS 上で自身で作成した API が確認できます。 削除コマンド 今回作成したリソースは認証のかかっていない API になっています。 なので削除コマンドも載せておきます。 samコンテナ /app $ aws cloudformation delete-stack --stack-name sam-app --profile default 最後に Swagger と API Gateway を連携することで Swagger の API 定義書と API Gateway の実際のリソースが同期されるようになりました。 連携しておけば、「API定義書が古い！！」といった事象も起こりにくくなると思います。 こういった初期プロジェクトの作成はなかなか全員の開発者が触れるものではないので貴重な体験です。 また、プロジェクトの最初にしか実行しないので、悪戦苦闘することが多いです。 そういった方に見てもらえると幸いですm(_ _)m 今回は手動でデプロイしましたが、これらを自動で開発、ステージ、本番へデプロイしたりテストステージを組み込んだ CI・CD 環境を作ることもできます。 それらは次回ご紹介しようと思いますm(_ _)m

概要 AWS Lambda と Amazon API Gateway を本番環境で利用するときの Docker 開発環境です。 ここでは API 定義に Swagger を利用しています。 目次 環境構成 　・前提条件 　・開発環境で作成するファイル 　・AWS 上に作成されるリソース 開発環境作成手順 　・フォルダ構成 　・AWS SAM CLI 用 の Python ベースの dockerfile 作成 　・docker-compose.yml の作成 　・swagger.yml の作成 　・docker-compose の起動 　・AWS SAM CLI を使った Lambda 関数の作成 　　　・コンテナへのアタッチ 　　　・AWS SAM CLI の実行と初期プロジェクトの作成 　・template.yaml の実装 　・ソースコードの実装 　・S3 バケットの作成 　・swagger.yml を S3 へアップロード 本番デプロイ準備 　・samconfig.toml の作成 　・ビルド 本番デプロイ 　・作成されたリソースの確認 いざコード開発の開始！！ 削除コマンド 最後に 環境構成 作成するファイルや実際に AWS 上に作成されるリソースです。 前提条件 著者は Mac 環境で動作検証を行っております。 Docker を利用するのでインストールしておいてください。 ホストサーバーに ~/.aws フォルダと config ファイルにcredential や profile 情報が設定されていることを前提で進めます。 まだ、設定していない方は AWS CLI のインストールと AWS CLI の設定方法を参考にしてください。 開発環境で作成するファイル AWS SAM CLI と node.js のビルド環境を動かす Python用の Dockerfile API Gateway と Lambda の環境を構築する template.yaml API Gateway の API エンドポイントなどを定義する swagger.yml SAM のビルド & デプロイ用の設定ファイル samconfig.toml Node.js のパッケージ管理ファイル package.json AWS SAM CLI と Swagger Editor のコンテナを起動する docker-compose.yml lambda で実行されるソースコード一式 ※ 開発環境と言っても、今回ご紹介する手順は最終的に AWS 上へデプロイする形になります。 AWS SAM では lambda をローカルでエミュレートできるみたいですが今回は試していません。 AWS 上に作成されるリソース Swagger の swagger.yml ファイル と SAM の template.yaml を保存する S3 バケット （手動作成） API Gateway SAM から自動生成される Lambda 用の IAM Role Lambda (nodejs14) 開発環境作成手順 では、開発環境を作成していきます。 フォルダ構成 下記が作成するフォルダ構成です。 Project │── Dockerfiles │ └── python │ └── Dockerfile ├── README.md ├── docker-compose.yml ├── sam-app │ ├── README.md │ ├── events │ ├── hello-world │ │ ├── app.js │ │ ├── node_modules │ │ ├── package.json │ │ ├── tests │ ├── samconfig.toml │ └── template.yaml └── swagger.yml Dockerfiles:　利用するコンテナを定義した dockerfile 群 sam-app:　AWS SAM CLI で作成される初期ソースコードのテンプレート docker-compose.yml:　Dockerfiles で定義したコンテナを管理 & 実行 swagger.yml:　Swagger で定義した OPEN API 設計ファイル AWS SAM CLI 用 の Python ベースの dockerfile 作成 AWS SAM CLI を実行する Dockerfile を作成します。ついでに node.js をビルドする npm も Python コンテナにインストールしてしまいます。ここは node コンテナと分けてもらっても構わないですが、特に Web サーバとして動かす必要がないので、 Python コンテナに npm を同居させています。 Dockerfiles/python/Dockerfile FROM python:3.9-alpine ENV NODE_PATH /usr/lib/node_modules/ # install nodejs RUN apk update \ && apk add --no-cache \ nodejs \ npm \ gcc \ libc-dev \ git # install aws-cli RUN pip3 install awscli # install aws-sam-cli RUN pip3 install -U aws-sam-cli # change work directory RUN mkdir -p /app WORKDIR /app docker-compose.yml の作成 docker-compose.yml です。先ほど作成した AWS SAM CLI 用の Dockerfile と Swagger Editor をローカルで動かすコンテナを実行します。 docker-compose.yml version: "3.5" services: sam: build: context: ./dockerfiles/python/ dockerfile: Dockerfile tty: true # 後でコンテナ内にアタッチするので tty と stdin_open を true にする stdin_open: true image: sam working_dir: /app volumes: - .:/app # ホストのプロジェクトフォルダをコンテナ内の /app にマウント - ~/.aws:/root/.aws # aws cli をコンテナから操作できるようにホストの .aws をマウント container_name: sam swagger: ports: - "8081:8080" image: swaggerapi/swagger-editor working_dir: /app environment: # コンテナ内の swagger 定義ファイルパス - SWAGGER_FILE=/app/swagger.yml volumes: - .:/app - ~/.aws:/root/.aws container_name: swagger swagger.yml の作成 swagger.yml に API 定義を記述していきます。今回はサンプルとして、Swagger 公式が上げている OpenAPI 3.0 の petstore を参考に AWS API Gateway に対応させるように改造していきます。 今回サンプル用に改造した yaml ファイルが下記になります。 swagger.yml openapi: "3.0.0" info: version: 1.0.0 title: Swagger Petstore license: name: MIT servers: - url: http://petstore.swagger.io/v1 paths: /pets: get: summary: List all pets operationId: listPets tags: - pets parameters: - name: limit in: query description: How many items to return at one time (max 100) required: false schema: type: integer format: int32 responses: '200': description: A paged array of pets headers: x-next: description: A link to the next page of responses schema: type: string content: application/json: schema: $ref: "#/components/schemas/Pets" default: description: unexpected error content: application/json: schema: $ref: "#/components/schemas/Error" x-amazon-apigateway-integration: uri: # APIからキックするLambda関数のARN Fn::Sub: arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${PetStoreFunction.Arn}/invocations passthroughBehavior: when_no_templates httpMethod: GET type: aws_proxy post: summary: Create a pet operationId: createPets tags: - pets responses: '201': description: Null response default: description: unexpected error content: application/json: schema: $ref: "#/components/schemas/Error" x-amazon-apigateway-integration: uri: # APIからキックするLambda関数のARN Fn::Sub: arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${PetStoreFunction.Arn}/invocations passthroughBehavior: when_no_templates httpMethod: POST type: aws_proxy ########### 以下省略 ########### components: ########### 以下省略 ########### 追加した箇所は、下記2箇所です。 x-amazon-apigateway-integration: uri: # APIからキックするLambda関数のARN Fn::Sub: arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${PetStoreFunction.Arn}/invocations passthroughBehavior: when_no_templates httpMethod: POST ## POST のエンドポイントは GET を指定する type: aws_proxy x-amazon-apigateway-integration: uri: # APIからキックするLambda関数のARN Fn::Sub: arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${PetStoreFunction.Arn}/invocations passthroughBehavior: when_no_templates httpMethod: GET ## GET のエンドポイントは GET を指定する type: aws_proxy 他はすべて、参考にした github のコードのままになります。 ここでは、API Gateway がキックする Lambda を定義しています。 Swagger で定義した API Gateway のエンドポイントパスを叩くと、ここで定義した lambda が実行されるといった処理になります。 x-amazon-apigateway-integration に定義する httpMethod は swagger で定義したエンドポイントパスに対応するメソッドを指定してください。 また uri には後述する Lambda 関数の ARN を指定します。したがって ${PetStoreFunction.Arn} は、ご自身の環境の Lambda 関数名.arnを指定してください docker-compose の起動 ここで一度 docker-compose up で Docker コンテナを起動してみます。 起動が完了したら localhost:8081 にアクセスしてみます。 下記のように Swagger Editor が表示されたら OK です。 ブラウザの Swagger Editor で修正した yaml ファイルはローカルには自動で反映されないので、必ずローカルのIDE または エディタから編集してブラウザで確認といった形で修正内容を確認しましょう。 もしブラウザで修正したい場合は yaml ファイルをブラウザで修正後ダウンロードもできます。 AWS SAM CLI を使った Lambda 関数の作成 続いて、立ち上げた AWS SAM CLI 用のコンテナ（コンテナ名: sam）にアクセスして AWS SAM CLI を実行し初期プロジェクトを作成します。 コンテナへのアタッチ ▼ コマンドの方は下記コマンドを実行します。 ホスト $ docker exec -it sam /bin/sh ▼ VSCodeの場合は Docker Extension からコンテナ内へアタッチすることができます。 AWS SAM CLI の実行と初期プロジェクトの作成 アタッチしたコンテナ内で AWS SAM CLI を実行して初期プロジェクトを作成します。 AWS SAM CLI の AWS 公式チュートリアルを参考にしています。 ▼ 実行した SAM CLI のコマンド（選択した選択肢のみ記載しています） samコンテナ /app $ sam --version # SAM CLI, version 1.18.1 /app $ sam init Which template source would you like to use? 1 - AWS Quick Start Templates What package type would you like to use? 1 - Zip (artifact is a zip uploaded to S3) Which runtime would you like to use? 1 - nodejs14.x AWS quick start application templates: 1 - Hello World Example # 出力結果 ----------------------- Generating application: ----------------------- Name: sam-app Runtime: nodejs14.x Dependency Manager: npm Application Template: hello-world Output Directory: . Next steps can be found in the README file at ./sam-app/README.md 上記のようにテンプレートを作成するための選択肢が出てきます。 今回は nodejs で lambda を開発するので Runtime は nodejs14.x を選びました。 デプロイ先は S３ にしております。 その他の選択肢は上記を参考にしてください。 テンプレートが作成されるとプロジェクトフォルダに hello-world フォルダが作成されます。 template.yaml の実装 ここでは、チュートリアルで作成された template.yaml を編集し swagger に対応させるように修正します。 追記する観点は下記２項目です。 API Gateway の定義を追加 Lambda function にエンドポイントパスイベントを定義 ※ 上記２点の修正箇所に伴って Outputs の値なども修正しております。 template.yaml AWSTemplateFormatVersion: '2010-09-09' Transform: AWS::Serverless-2016-10-31 Description: > sam-app Sample SAM Template for sam-app Globals: Function: Timeout: 3 Parameters: # swagger.yml をアップロードしているバケット名 BucketName: Type: String Resources: # PetStore 用の API Gateway を定義 PetStoreApi: Type: AWS::Serverless::Api Properties: Name: !Ref "AWS::StackName" StageName: prod OpenApiVersion: 3.0.0 DefinitionBody: Fn::Transform: Name: AWS::Include Parameters: Location: !Sub s3://${BucketName}/swagger.yml # Lambda 関数の設定を定義 (Hello-world のコードを流用) PetStoreFunction: Type: AWS::Serverless::Function Properties: CodeUri: hello-world/ Handler: app.lambdaHandler Runtime: nodejs14.x Events: PetsGet: Type: Api Properties: Path: /pets Method: get RestApiId: !Ref PetStoreApi # API を参照 PetsPetIdGet: Type: Api Properties: Path: /pets/{petId} Method: get RestApiId: !Ref PetStoreApi # API を参照 PetsPost: Type: Api Properties: Path: /pets Method: post RestApiId: !Ref PetStoreApi # API を参照 Outputs: PetStoreApi: Description: "API Gateway endpoint URL for Prod stage for Hello World function" Value: !Sub "https://${PetStoreApi}.execute-api.${AWS::Region}.amazonaws.com/Prod/pet/" PetStoreFunction: Description: "Hello World Lambda Function ARN" Value: !GetAtt PetStoreFunction.Arn PetStoreFunctionIamRole: Description: "Implicit IAM Role created for Hello World function" Value: !GetAtt PetStoreFunctionRole.Arn 注目するところは下記設定です。 PetStoreApi に OpenApiVersion: 3.0.0 を指定する。 PetStoreApi の DefinitionBody に swagger.yml をアップロードした S3 バケット URL をセットする。 OpenApiVersion: 3.0.0 DefinitionBody: Fn::Transform: Name: AWS::Include Parameters: Location: !Sub s3://${BucketName}/swagger.yml PetStoreFunction の Events に swagger.yml で定義したエンドポイントパスを定義する。 Events: PetsGet: Type: Api Properties: Path: /pets Method: get RestApiId: !Ref PetStoreApi # API を参照 ソースコードの実装 Lambda Function のソースコードを実装します。 ここでは、サンプルのためチュートリアルのコードのままにします。 S3 バケットの作成 ビルドされた template.yaml やコード、 swagger.yml を保存する S3 バケットを手動で作成します。 samコンテナ /app $ aws s3 mb s3://sam-app-bucket-pfr379vgrp0 --profile default swagger.yml を S3 へアップロード 先ほど作成した S3 バケットに swagger.yml ファイルをアップロードします。 samコンテナ /app $ aws s3 cp swagger.yml s3://sam-app-bucket-pfr379vgrp0/swagger.yml --profile default 以上が開発環境の作成です。次に AWS 環境へデプロイする準備を行います。 本番デプロイ準備 本番へデプロイするための準備を行います。 samconfig.toml の作成 デプロイするための情報を toml 形式で sam-app 直下に保存します。 sam-app/samconfig.toml version=0.1 [default.deploy.parameters] stack_name = "sam-app" s3_bucket = "sam-app-bucket-pfr379vgrp0" s3_prefix = "sam-app" region = "ap-northeast-1" confirm_changeset = true capabilities = "CAPABILITY_IAM" ビルド AWS SAM CLI を利用してコードのビルドを行います。 samコンテナ /app $ cd sam-app /app/sam-app $ sam build ビルドが完了し、.aws-sam フォルダに build フォルダが作成されていればビルドが成功です。 ちなみに自動で npm install コマンドが実行され node_module をビルドに含めてくれているみたいです。 本番デプロイ 最後にデプロイを行います。 samコンテナ /app/sam-app $ sam deploy --profile default --config-env default --parameter-overrides BucketName=sam-app-bucket-pfr379vgrp0 ### 省略 ### Previewing CloudFormation changeset before deployment ====================================================== Deploy this changeset? [y/N]: y 2021-04-14 08:23:23 - Waiting for stack create/update to complete CloudFormation events from changeset ### 省略 ### Successfully created/updated stack - sam-app in ap-northeast-1 オプション 解説 --profile AWS CLI の ~/.aws/config に設定した profile。自身のデプロイ先のAWSアカウントを指定してください。 デフォルト: default --config-env samconig.toml の設定情報 deploy.parameters の前の文字列を指定します。 デフォルト: default ---parameter-overrides template.yaml の Parameters に定義したパラメータをここで指定できます。 Successfully が表示されたらデプロイの完了です。 作成されたリソースの確認 ▼ API Gateway のリソースとステージ ▼ Swagger で定義したモデルの確認 いざコード開発の開始！！ これで環境構築と、デプロイができました！！ あとは、Lambda Function の開発を行い、コードを修正したら上記手順でまたビルド & デプロイ すると AWS 上で自身で作成した API が確認できます。 削除コマンド 今回作成したリソースは認証のかかっていない API になっています。 なので削除コマンドも載せておきます。 samコンテナ /app $ aws cloudformation delete-stack --stack-name sam-app --profile default 最後に Swagger と API Gateway を連携することで Swagger の API 定義書と API Gateway の実際のリソースが同期されるようになりました。 連携しておけば、「API定義書が古い！！」といった事象も起こりにくくなると思います。 こういった初期プロジェクトの作成はなかなか全員の開発者が触れるものではないので貴重な体験です。 また、プロジェクトの最初にしか実行しないので、悪戦苦闘することが多いです。 そういった方に見てもらえると幸いですm(_ _)m 今回は手動でデプロイしましたが、これらを自動で開発、ステージ、本番へデプロイしたりテストステージを組み込んだ CI・CD 環境を作ることもできます。 それらは次回ご紹介しようと思いますm(_ _)m

(Amazon Linux 2 より前の) Amazon Linux AMI プラットフォームで、Elastic Beanstalk のマルチDocker 環境をECSを使って構築する。 BuildしたDockerイメージをECRにプッシュした際に、以下のようなエラーが発生。 ECS Application sourcebundle validation error: We expected a VALUE token but got: START_OBJECT 結論から言うと、Dockerrun.aws.jsonのcommandプロパティが配列である必要があるが、Stringになっていた。 以下を参照のこと。 Weaponizing Haskell - Part Two: Deployment ~ Bows and Arrows 抜粋 One of the main issues I had was that my command property for one of my services was a string, but it should have been an array. Docker-Compose allows this, but Dockerrun doesn’t. I ended up reading the ECS Task-Definition Parameters manual with much more scrutiny and realized my mistake. Part of why it took me so long to do so was because of the misleading error message.

ホストのCentOS-7.3を再起動後、docker上のMySQLに接続できなくなった。 その際の備忘録。 dockerの状態を確認 $ systemctl status docker ● docker.service - Docker Application Container Engine Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; vendor preset: disabled) Active: active (running) 起動している。 コンテナを確認 $ sudo docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 起動しているコンテナなし 停止しているものも含めてコンテナ確認 sudo docker ps -a 接続したかったコンテナが存在した。 コンテナが停止していたことがわかった。 コンテナの起動 $ sudo docker start コンテナ名 起動失敗。以下エラー文抜粋 iptables: No chain/target/match by that name. iptables(ファイアーウォール)のルール確認 $ sudo iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination dockerの設定がない dockerを再起動する $ sudo systemctl restart docker 再度iptables(ファイアーウォール)のルール確認 $ sudo iptables -L dockerの設定が反映された コンテナに接続後、MySQLへ接続できた。 参考サイト

概要 PC 交換をした 以下に沿って WSL2 のボリュームの引っ越しをした https://forest.watch.impress.co.jp/docs/serial/yajiuma/1220926.html Docker Desktop も入れ直した うまく WSL2 と連携されず、 docker コマンドが使えなかった 設定に問題がなさそうであればログをみるのが手っ取り早い 環境 Windows 10 WSL2 + Ubuntu 18.04 Docker Desktop for Windows 2.3.0.4 現象 WSL Integration が有効になっているのに docker コマンドが使えない。 $ docker ps Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running? ログの参照 Troubleshoot -> Run Diagnostics -> logfile もしくは C:/Users/<User Name>/AppData/Local/Docker/log.txt を直接開く 今回の原因 [12:37:48.751][WslIntegrationAgent-Ubuntu1804][Info ] time="2021-04-14T12:37:48+09:00" level=fatal msg="mkdir /mnt/c/Users/ogawa/key.pem: permission denied" なぜか mkdir で permission denied になっていた。 PC 交換に伴って Windows のユーザー名が ogawa -> t_ogawa へ変更となっていたため、 /mnt/c/Users/ogawa/key.pem は現 PC には存在していなかった。 そこで /mnt/c/Users/ogawa ディレクトリを作って key.pem を置いてあげたところエラーは解消され、 $ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES docker コマンドが打てるようになった。 なお、key.pem は自前のコンテナの起動スクリプトで利用するものであった。 まとめ docker の動作がおかしいときはログをみる

Chromebook の linux 開発環境で容量が逼迫したので、スペースを確保するためにローカルの Docker イメージを一括削除したときのコマンドを備忘録として残しておく。 for img in $(docker images|awk '{pring $3}'|sed -e '1d' -) do docker rmi $img done

はじめに DockerでNode-REDコンテナからPostgresコンテナへ接続する際に少し沼った。 「ECONNREFUSED」が出てきて接続できなかった。 2か所ほど設定を間違っていたので、備忘録として。 状況 Dockerで下記コンテナ間で接続を試みた Node-RED Postgres docker-compose.ymlを用いた立ち上げ version: '3' services: postgres: image: postgres container_name: postgres ports: - '6432:5432' volumes: - (略) environment: POSTGRES_USER: postgres POSTGRES_PASSWORD: ***** nodered: image: nodered/node-red container_name: nodered ports: - '2880:1880' volumes: - (略) Node-REDのノード、設定は下記の通り ノード: node-red-contrib-postgres-variable Host: localhost Port: 6432 Database: postgres Username: postgres Password: ***** 解消 Node-REDのノード設定が間違っていた。 Host 内部接続ではあるものの、ホストはlocalhostではなくpostgresにしなければならなかった。 コンテナ間の接続は同ネットワーク内での接続ということで、IPアドレスなどを指定するのではなく、コンテナ名を指定する必要があると思われる。 たしかにlinksのような内部接続の設定を考慮すると当然といえば当然かもしれない。 ちなみに、Postgresのコンテナ内でhostnameコマンドを実行すると、コンテナのIDが出力される。 Port ポートの設定をポートフォワーディングで設定していた6432に設定していたが、正しくは元の5432を指定しなければならかった。 ポートフォワーディングはあくまで外部から接続があった場合の設定なので、同じネットワーク内にあるコンテナ間の接続では、既存のポートを設定する必要があると思われる。 そりゃそうか。 終わりに Dockerでコンテナを立ち上げて作業しているということを忘れていると、このような現象に見舞われる気がする。 Dockerの基礎知識をもっと付けておかないと、よくわからないところで沼るなと改めて思った。 最後まで読んでいただきありがとうございます。 認識が違っている点などがあれば、ぜひご指摘ください！ （特にDockerは詳しくないので、今後誰かの助けとなるようブラッシュアップしていきたいです！）

転載元 当記事は以下ブログからの転載です。 TECH BACK はじめに 今まで、Visual Studio2019でDjango開発してましたが、VS CodeだとDocker対応してるみたいなんで、やってみました。 こういったのは、多分すぐ忘れるので残しとかないとね。 VS Codeのインストールから サイトに行って、ダウンロードしてきましょ。 https://azure.microsoft.com/ja-jp/products/visual-studio-code/ 今回は、WindowsのUser Installer版をダウンロード インストーラ実行 そのまま、次へ次へ。。。無事インストール完了。 Extention周りをインストールします。 VS Codeは、Extentionいっぱいあって、楽しいかも！ ここで紹介した以外にも、色々あるので、当分楽しめそうね～? Remote -WSL (結局、使わなかった) で、起動したら、下記メッセージ そう言えば、Dockerインストールする時に、WSL2を入れてました。 便利そうなので、Installボタンクリック。 Docker 検索して、Dockerもインストールしておきましょう。 アイコンすぐ右のInstallボタンをクリック(緑のやつね) 左のアイコン並んでる所に、くじら出てきましたね～ クリックしたら、CONTAINERSの所に用意したコンテナいますね。 コンテナ上で右クリックすると、、、 ここで、コンテナの操作できるんですね。便利じゃないか！ Remote - Containers Dockerのコンテナに、接続するやつ！ いつもどおり、インストールして～ Docker Containerに接続！ VS Codeの左下の、><をクリックすると、、、、 どこに接続しますの？？と、 で、Remote-Containers: Attach to Running Container... をクリック Djangoが入ってる方(上)を選択、 別Windowが開いて、左下の方にメッセージが。多分うまく行ってるのかな？？ こっちはこっちで、Extention入れないとダメなのね こっちの環境の方にも、Python Extention入れておきましょうか！ Install in Container ＊＊＊の所をクリックして、インストール ちょっとしたら、Install in Container ***のところが、Reload Requiredに変わったので、クリック。 再度読み直ししたとおもったら、下のメッセージ。 PythonのVersion指定しろと？？ 最新の、3.8で行きます コチラも、Installします。 デバッグしてみますかね～ Djangoプロジェクトのパス指定 ターミナルを立ち上げて、 フォルダを検索してみたら、どうも /codeって所に、Djangoのフィアル郡があるもよう。 デバッグの画面に遷移して、open a folderをクリックすると、 Djangoプロジェクトの設置パスを指定しろと。manage.pyがあるフォルダ。 指定して、OK デバッグ用のJsonファイル作成 今度は、create a launch.json file.をクリック Djangoをクリック できた～ よし！早速適当な所に、ブレークポイント貼って、 Run and Debug ま、そっか～。コンテナ起動の時に、Django立ち上がってますよね～。 launch.jsonに、赤字の1行追加しました。 デバッグの時は、PORTを違うので動かします。 { // Use IntelliSense to learn about possible attributes. // Hover to view descriptions of existing attributes. // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387 version: 0.2.0, configurations: [ { name: Python: Django, type: python, request: launch, program: ${workspaceFolder}/manage.py, args: [ runserver, <span style="color:">0.0.0.0:8001,</span> --noreload ], django: true } ] } そして、再度デバッグ実行！ 来た～～ 今回はここまで。 次は、AWSにDocker Container乗っけて見ますかね。

転載元 当記事は以下ブログからの転載です。 TECH BACK はじめに 前回、Windows10 Home環境にDockerのインストールができたので、早速Django環境を作っていこうかと。 Dockerのページに、解説ページがあったので、そちらを参考にすすめていきます。 http://docs.docker.jp/v1.9/compose/django.html プロジェクトの構成ファイル郡を作りましょう プロジェクト用のフォルダ作成 コチラは適当に。分かりやすいのを作っとけばOKでしょ。 こんなフォルダでいいかな～ E:\docker\django_env Dockerfileってのを作りましょう 作ったフォルダの直下に、Dockerfileという拡張子無しのファイルを作成します。 Djangoが動くサーバ（コンテナ）の設定を記載していきます。 そして、開いて編集 FROM python:3.8 ENV PYTHONUNBUFFERED 1 RUN mkdir /code WORKDIR /code ADD requirements.txt /code/ RUN pip install -r requirements.txt ADD . /code/ Documentだと、Python2.7でしたけど、今から作るなら3系ですね。 Python公式だと、https://www.python.org/ 3.8が最新っぽかったので、そちらに変更。 ### requirements.txtを作成 またまた、作ったフォルダに requirements.txt というファイルを作りましょう。 今ファイルには、上記で作ったDjangoが動くコンテナに、使用するライブラリを記載していきます。Django環境を作る際にPipコマンドでインストールするものを、ここに記載しておきます。 内容は <span class="n">Django psycopg2</span> で、保存しておきましょう。まずは、動かすだけなので、コレでOKです。 今度は、docker-compose.ymlってファイルを作成 同じく、作ったフォルダ直下にdocker-compose.yml というファイルを作成 内容は、 db: image: postgres web: build: . command: python manage.py runserver 0.0.0.0:8000 volumes: - .:/code ports: - 8000:8000 links: - db で、保存 ファイルの構成 今までの流れをやっていくと、こんな感じですね。 作ったフォルダの直下に、ファイルを3つ作りました。 Djangoプロジェクト作成 コマンドプロンプトで、先程作ったフォルダに移動します。 > コマンドプロンプトでドライブ移動 ちょっと脱線しちゃいますが、、、 え～どうやるんだっけ～って、なったので一応記載。 > C:\>e: > > e:\> > 移動したら、こんな感じね。 e:\docker\django_env>dir e:\docker\django_env のディレクトリ 2020/05/24 02:21 <DIR> . 2020/05/24 02:21 <DIR> .. 2020/05/24 02:23 168 docker-compose.yml 2020/05/24 01:48 151 Dockerfile 2020/05/24 02:20 16 requirements.txt 3 個のファイル 335 バイト 2 個のディレクトリ 713,117,704,192 バイトの空き領域 e:\docker\django_env> そしてフォルダに移動したら、コマンドを実行しましょう。 ちなみに、最後の「composeexample 」という所がプロジェクト名ね。今回は、サンプルのままで。 docker-compose run web django-admin.py startproject composeexample . 各種ダウンロードしますんで、結構時間かかります。。。 そして、実行後にフォルダを覗いて見ると ちゃんと、composeexampleフォルダができてますね。 データベースに接続 composeexampleフォルダの下に、setting.pyがあるので、そいつを編集。 DATABASESの箇所をこんな感じに。 DATABASES = { 'default': { 'ENGINE': 'django.db.backends.postgresql_psycopg2', 'NAME': 'postgres', 'USER': 'postgres', 'HOST': 'db', 'PORT': 5432, } } で、保存 いよいよ、動かす コマンドを実行 docker-compose up あら、、エラーが Starting django_env_db_1 ... done Creating django_env_web_1 ... error ERROR: for django_env_web_1 Cannot start service web: Cannot link to a non running container: /django_env_db_1 AS /django_env_web_1/db ERROR: for web Cannot start service web: Cannot link to a non running container: /django_env_db_1 AS /django_env_web_1/db ERROR: Encountered errors while bringing up the project. django_env_db_1 が、動いてませんぜ～ってことですね。 Docker Dashboardを開いて、django_env_db_1 のLogsを見てみると、、 まずDBのInitializeしろと。 docker-compose.yml にパスワードを追記してやります。 db: image: postgres <span style="color:"> environment:</span> <span style="color:"> POSTGRES_PASSWORD: Password</span> web: build: . command: python manage.py runserver 0.0.0.0:8000 volumes: - .:/code ports: - 8000:8000 links: - db settings.py にも、パスワードを追加します。 DATABASES = { 'default': { 'ENGINE': 'django.db.backends.postgresql_psycopg2', 'NAME': 'postgres', 'USER': 'postgres', 'HOST': 'db', 'PORT': 5432, <span style="color:">'PASSWORD': 'Password'</span> } } そして、再度 docker-compose up ん、、、、今度はうまく行ったみたい。 http://localhost:8000/ に、アクセスしてみると。。。 感想とか ん～思ったより早く行ったな。といった感想。 自分でイチから環境作った時は、結構時間掛かった記憶。(もう二度とやりたくないとか、ちょっと思ってるぐらい) これなら、思い立ったら簡単にプロトタイプ作っちゃおうかな～とか思ったりできるよね。 今後 自分のLocal環境にはDocker環境できましたんで、 1. ちょっとしたサンプルアプリをLocalで開発 2. AWSにDocker受け入れ環境を作って、デプロイ！ って感じでやってみますかね。

転載元 当記事は以下ブログからの転載です。 TECH BACK きっかけ CentOSにDjango/MariaDBという環境で、Webアプリ作っていますが、まー環境づくりが大変だった！ Dockerで、この環境周りが楽になるって言われてますし、勉強がてら導入していきます。 目指す所 やっぱり、ローカルの開発環境をそのまま、サーバにデプロイできたら最高かな～と。 別件ですが、DjangoのMigrationとか毎回つまづくので、２～３時間かかっているような。。。ここらへのも、Dockerでうまく回避できたら最高だなと。。。 まずローカル環境つくりますかね。 私のLocal環境ですが、 Windows10 Home こいつで、開発環境作っていきます。 Dockerをインストール https://docs.docker.com/docker-for-windows/install/ Download from Docker Hubボタンをクリックして Dockerhubに遷移 で、Get dockerボタンをクリック ようやくインストーラGet そして、インストール！！ あれー、バージョン古いのかね。 > Installation failed: one prerequisite is not fullfilled Windows 10 Home(19018+) って言われてますし。 Windowsのアップデート しょうがない、私の場合 Windows10 Homeなので、19018以上にしたらよいのね。多分。。 現在は、 Windows Insider Programで、スローにしておいてくださいね。 Windows Updateチェックします 準備しています が、なかなか進みません? まぁ、待ちましょう ・・・・? これは、寝てる間に仕掛けておく系ですね。 再起動したら、結構待たされるやつでしょ。騙されないからな！ 意を決して再起動！！ 10分強で完了。(思ったより早いわ) 確認したら、OSビルドが19041 19018はクリアしたっぽいですね。 再度、Dockerインストール 再度、インストーラを起動 お！今度は、ちゃんと行きそうですね。 チェックはそのままで、OKボタンクリック 再起動～ Close and restartボタンをクリック WSL2ってのが、インストールうまく行かなかったみたい Windows の再起動が終わったら、下のウインドウが、、、 WSL 2 installation is incomplete. The WSL 2 Linux kernel is now installed using a separate MSI update package. Please click the link and follow the instructions to install the kernel update:https://aka.ms/wsl2kernel. Press Restart after installing the Linux kernel. とりあえず、記載されているURLをクリック。→ Microsoftの「WSL 2 Linux カーネルの更新」解説ページが表示されます。 ページ内にある、WSL2 Linuxカーネル更新プログラムパッケージとやらをダウンロード ダウンロードしたインストーラを実行 なんかあっさり終わったな 改めて、Restartボタンクリック！ うまく行ったっぽい このウイザードも、対応しておきますか。Startボタンをクリック をぉ～右半分がPowerShell画面だ いちいち打ち込まなくてOKで、真ん中の「git clone...」ってコマンド書いている所をクリックしたら、右に反映＆実行されます。そして、Next step 今度は、Buildですね。同じように、コマンド記載部分をクリックして、完了まで待つ。。。 終わったら、Next Step そして、Run 次のShareは、しなくていいかな～で、Done そして、Chromeとかブラウザで、http://localhostにアクセスすると、Dockerのチュートリアルページが表示されました。インストールと、デモの実行までうまく行ったみたい。

目標 aws のコマンドを、ローカルは散らかさずに使いたい 使うためにはそれ用のパッケージをインストールする必要があるが、それはインストールしたくない 前提 Docker コマンドが使える やり方 $ docker run --rm -it -v ~/.aws:/root/.aws -v (pwd):/aws -e AWS_ACCESS_KEY_ID -e AWS_SECRET_ACCESS_KEY -e AWS_DEFAULT_REGION amazon/aws-cli usage: aws [options] <command> <subcommand> [<subcommand> ...] [parameters] To see help text, you can run: aws help aws <command> help aws <command> <subcommand> help 環境変数を使って認証できるので、 direnv を使うと相性が良い alias aws で呼び出せて、docker を意識せず使えるので便利 bash_profile alias aws "docker run --rm -it -v ~/.aws:/root/.aws -v (pwd):/aws -e AWS_ACCESS_KEY_ID -e AWS_SECRET_ACCESS_KEY -e AWS_DEFAULT_REGION amazon/aws-cli"

はじめに 仕事の進みが悪すぎて現実逃避したくなったので、気になっていたReactをさわってみることにしました。 ４月ということで、新入社員や、学生の方でも作業しやすいようにGUI操作多めで記述していこうと思います。 バックエンドはPython＋FastAPIでサクッと作って組み合わせていきます。 開発環境 以下の環境を準備してください。 インストール手順は説明しませんが、インストーラーのリンクは張っておきます。 Windows 10 Pro Docker Desktop for Windows を使うので、Pro環境を想定。 簡易的なことしかしないので、dockerが動作すればMac、Linuxでも良いです。 docker Docker Desktop for Windows で説明をします。 CUIに慣れていない人向けにGUIでの操作を記載しますが、詳しい人はCUIでの操作を推奨。 インストーラー Get Dokcerをクリックしてダウンロードし、インストーラーを実行する。 Visual Studio Code インストーラー Windowsをクリックしてダウンロードし、インストーラーを実行する。 Python,JavaScript,dockerfileの編集を行うので、以下の拡張機能を入れてください。 拡張機能 Visual Studioを起動して、左側の拡張機能のアイコンをクリックし、入力欄で以下を検索してインストールしてください。 名前 説明 Japanese Language Pack for Visual Studio Code 日本語環境 Python Python言語用 Docker Docker用 Remote - SSH リモート作業用 Remote - Containers リモート作業用 Remote - SSH: Explorer リモート作業用 Remote Development リモート作業用 docker環境 １．任意のフォルダを作成 エクスプローラーを右クリックして、[新規作成] - [フォルダー] をクリック。任意の名前を設定します。 例:sample ２．Visual Studio Codeで開く 1で作成したフォルダを開き、右クリックで、[Codeで開く] をクリックし、Visual Studio Codeで開きます。 ３．dockerfileの作成 右クリックで[新しいファイル]をクリックします。 ファイル名にdockerfileを指定し、ファイルの内容は以下をコピペします。 FROM node:lts-alpine RUN apk update && apk add --virtual=module curl git python3 python3-dev py3-pip RUN npm install -g create-react-app RUN npm install axios RUN pip3 install uvicorn fastapi requests WORKDIR /usr/src/app EXPOSE 8000 3000 ４．dockerfileをビルド dockerfileを右クリックして、[Build Image...]をクリックします。 イメージの名前を入力してEnterキー。(デフォルトのままでOK) 例：sample:latest ダウンロードに少し時間がかかります。 ５．dockerのコンテナの作成 左のバーの"くじら"のアイコン(赤枠)をクリックします。 作成した名前のイメージがツリーで表示される(緑枠)ので右クリックして[Run Interactive]をクリックします。 コンテナが作成されるとツリーに表示されます。(青枠) ６．コンテナへの接続(ターミナル) コンテナを右クリックして[Attach Shell]をクリック。 黄枠の部分にターミナルが表示されます。 ７．コンテナへの接続(Visual Studio Code) コンテナを右クリックして[Attach Visual Studio Code]をクリック。 別ウィンドウで、コンテナ内のフォルダでVisual Studio Codeが起動します。 [フォルダーを開く]ボタンをクリック。 開くパスを入力する欄が表示されるので、/usr/src/app を入力して[OK]ボタンをクリックする。 画面左に表示されるフォルダツリーでファイル操作ができます。 エクスプローラーからファイルをドロップしたり、右クリックで[ダウンロード]を実行することでコンテナ内のファイルをホストのＰＣに保存することができます。 フロントエンド(React) 6でコンテナに接続したターミナルで、以下を実行してReactのプロジェクトを作成します。 create-react-app my-app ダウンロードに時間がかかります。 作成されたmy-appフォルダに移動して、起動します。 cd my-app yarn start Chromeなどのブラウザを起動して、http://localhost:3000/ を表示するとデフォルトのページが表示されます。 バックエンド(Python+FastAPI) 7で表示したウィンドウを使いPython+FastAPIでバックエンドのREST APIを作成します。 React側から呼べるように、CORSを考慮して実装しておきます。 /usr/src/app の下にbg-appフォルダを作成し、その下にmain.pyを作成します。 main.py from fastapi import FastAPI from pydantic import BaseModel from starlette.middleware.cors import CORSMiddleware # uvicorn main:app --reload --host 0.0.0.0 app = FastAPI() app.add_middleware( CORSMiddleware, allow_origins=["*"], allow_credentials=True, allow_methods=["*"], allow_headers=["*"] ) class TestParam(BaseModel): param1 : str param2 : str # curl http://localhost:8000/ @app.get("/") def get_root(): return {"message": "fastapi sample"} # curl -X POST -H "Content-Type: application/json" -d '{"param1":"test1", "param2":"text2"}' http://localhost:8000/ @app.post("/") def post_root(testParam : TestParam): print(testParam) return testParam bg-appを右クリックして、[統合ターミナルで開く]をクリック。 表示されたターミナルで、以下を実行して起動する。 uvicorn main:app --reload --host 0.0.0.0 ブラウザを起動して、http://localhost:8000/ を表示するとjsonの応答が確認できます。 ソースのコメントに記載したcurlコマンドでも動作確認できます。 curl http://localhost:8000/ curl -X POST -H "Content-Type: application/json" -d '{"param1":"test1", "param2":"text2"}' http://localhost:8000/ React + FastAPI Reactのjsで、FastAPIに接続するコードを用意します。 my-app/srcフォルダ内にsample.jsを用意します。 sample.js import React from "react"; import axios from "axios"; class Sample extends React.Component { constructor(props) { super(props); this.state = { message1 : '', message2 : '' }; } handleClick = () => { axios .post("http://localhost:8000/" , { "param1": "hoge", "param2": "fuga"}) .then(res => { this.setState({ message1 : res.data.param1 , message2 : res.data.param2 }); }) .catch(err =>{ console.log(err); } ); }; render() { return ( <dev> <button onClick={this.handleClick}>POST</button> <p>メッセージ１={this.state.message1}</p> <p>メッセージ２={this.state.message2}</p> </dev> ); } } export default Sample; ボタンをクリックすると http://localhost:8000/ にPOSTでパラメータを渡して応答を画面に表示するSampleというコンポーネントを実装します。 my-app/src/App.jsにSampleコンポーネントを表示する処理を追加します。 App.js import logo from './logo.svg'; import './App.css'; import Sample from "./sample"; // 追加することで<Sample />が利用できる function App() { return ( <div className="App"> <header className="App-header"> <img src={logo} className="App-logo" alt="logo" /> <p> Edit <code>src/App.js</code> and save to reload. </p> <a className="App-link" href="https://reactjs.org" target="_blank" rel="noopener noreferrer" > Learn React </a> <Sample /> </header> </div> ); } export default App; ブラウザを起動して、http://localhost:3000/ を表示するとPOSTボタンが追加されていることが確認できます。 POSTボタンをクリックするとFastAPIにPOSTリクエストを送り、応答を画面に表示します。 おわりに dockerの操作はターミナルでのCUI操作が多めになって、初心者向けじゃないと思っていたので、Visual Stusio Codeの拡張機能を利用したGUI操作で説明を記載してみました。 本来はターミナルでdockerコマンドを利用するべきですので、慣れてきたらdockerコマンドを覚えてください。 Reactは、サンプル実行したくらいなのであまり理解が深まっていません。 次回は、こちらで解説したマインスイーパを作ることで理解を深める記事の予定です。

はじめに 仕事の進みが悪すぎて現実逃避したくなったので、気になっていたReactをさわってみることにしました。 ４月ということで、新入社員や、学生の方でも作業しやすいようにGUI操作多めで記述していこうと思います。 バックエンドはPython＋FastAPIでサクッと作って組み合わせていきます。 開発環境 以下の環境を準備してください。 インストール手順は説明しませんが、インストーラーのリンクは張っておきます。 Windows 10 Pro Docker Desktop for Windows を使うので、Pro環境を想定。 簡易的なことしかしないので、dockerが動作すればMac、Linuxでも良いです。 docker Docker Desktop for Windows で説明をします。 CUIに慣れていない人向けにGUIでの操作を記載しますが、詳しい人はCUIでの操作を推奨。 インストーラー Get Dokcerをクリックしてダウンロードし、インストーラーを実行する。 Visual Studio Code インストーラー Windowsをクリックしてダウンロードし、インストーラーを実行する。 Python,JavaScript,dockerfileの編集を行うので、以下の拡張機能を入れてください。 拡張機能 Visual Studioを起動して、左側の拡張機能のアイコンをクリックし、入力欄で以下を検索してインストールしてください。 名前 説明 Japanese Language Pack for Visual Studio Code 日本語環境 Python Python言語用 Docker Docker用 Remote - SSH リモート作業用 Remote - Containers リモート作業用 Remote - SSH: Explorer リモート作業用 Remote Development リモート作業用 docker環境 １．任意のフォルダを作成 エクスプローラーを右クリックして、[新規作成] - [フォルダー] をクリック。任意の名前を設定します。 例:sample ２．Visual Studio Codeで開く 1で作成したフォルダを開き、右クリックで、[Codeで開く] をクリックし、Visual Studio Codeで開きます。 ３．dockerfileの作成 右クリックで[新しいファイル]をクリックします。 ファイル名にdockerfileを指定し、ファイルの内容は以下をコピペします。 FROM node:lts-alpine RUN apk update && apk add --virtual=module curl git python3 python3-dev py3-pip RUN npm install -g create-react-app RUN npm install axios RUN pip3 install uvicorn fastapi requests WORKDIR /usr/src/app EXPOSE 8000 3000 ４．dockerfileをビルド dockerfileを右クリックして、[Build Image...]をクリックします。 イメージの名前を入力してEnterキー。(デフォルトのままでOK) 例：sample:latest ダウンロードに少し時間がかかります。 ５．dockerのコンテナの作成 左のバーの"くじら"のアイコン(赤枠)をクリックします。 作成した名前のイメージがツリーで表示される(緑枠)ので右クリックして[Run Interactive]をクリックします。 コンテナが作成されるとツリーに表示されます。(青枠) ６．コンテナへの接続(ターミナル) コンテナを右クリックして[Attach Shell]をクリック。 黄枠の部分にターミナルが表示されます。 ７．コンテナへの接続(Visual Studio Code) コンテナを右クリックして[Attach Visual Studio Code]をクリック。 別ウィンドウで、コンテナ内のフォルダでVisual Studio Codeが起動します。 [フォルダーを開く]ボタンをクリック。 開くパスを入力する欄が表示されるので、/usr/src/app を入力して[OK]ボタンをクリックする。 画面左に表示されるフォルダツリーでファイル操作ができます。 エクスプローラーからファイルをドロップしたり、右クリックで[ダウンロード]を実行することでコンテナ内のファイルをホストのＰＣに保存することができます。 フロントエンド(React) 6でコンテナに接続したターミナルで、以下を実行してReactのプロジェクトを作成します。 create-react-app my-app ダウンロードに時間がかかります。 作成されたmy-appフォルダに移動して、起動します。 cd my-app yarn start Chromeなどのブラウザを起動して、http://localhost:3000/ を表示するとデフォルトのページが表示されます。 バックエンド(Python+FastAPI) 7で表示したウィンドウを使いPython+FastAPIでバックエンドのREST APIを作成します。 React側から呼べるように、CORSを考慮して実装しておきます。 /usr/src/app の下にbg-appフォルダを作成し、その下にmain.pyを作成します。 main.py from fastapi import FastAPI from pydantic import BaseModel from starlette.middleware.cors import CORSMiddleware # uvicorn main:app --reload --host 0.0.0.0 app = FastAPI() app.add_middleware( CORSMiddleware, allow_origins=["*"], allow_credentials=True, allow_methods=["*"], allow_headers=["*"] ) class TestParam(BaseModel): param1 : str param2 : str # curl http://localhost:8000/ @app.get("/") def get_root(): return {"message": "fastapi sample"} # curl -X POST -H "Content-Type: application/json" -d '{"param1":"test1", "param2":"text2"}' http://localhost:8000/ @app.post("/") def post_root(testParam : TestParam): print(testParam) return testParam bg-appを右クリックして、[統合ターミナルで開く]をクリック。 表示されたターミナルで、以下を実行して起動する。 uvicorn main:app --reload --host 0.0.0.0 ブラウザを起動して、http://localhost:8000/ を表示するとjsonの応答が確認できます。 ソースのコメントに記載したcurlコマンドでも動作確認できます。 curl http://localhost:8000/ curl -X POST -H "Content-Type: application/json" -d '{"param1":"test1", "param2":"text2"}' http://localhost:8000/ React + FastAPI Reactのjsで、FastAPIに接続するコードを用意します。 my-app/srcフォルダ内にsample.jsを用意します。 sample.js import React from "react"; import axios from "axios"; class Sample extends React.Component { constructor(props) { super(props); this.state = { message1 : '', message2 : '' }; } handleClick = () => { axios .post("http://localhost:8000/" , { "param1": "hoge", "param2": "fuga"}) .then(res => { this.setState({ message1 : res.data.param1 , message2 : res.data.param2 }); }) .catch(err =>{ console.log(err); } ); }; render() { return ( <dev> <button onClick={this.handleClick}>POST</button> <p>メッセージ１={this.state.message1}</p> <p>メッセージ２={this.state.message2}</p> </dev> ); } } export default Sample; ボタンをクリックすると http://localhost:8000/ にPOSTでパラメータを渡して応答を画面に表示するSampleというコンポーネントを実装します。 my-app/src/App.jsにSampleコンポーネントを表示する処理を追加します。 App.js import logo from './logo.svg'; import './App.css'; import Sample from "./sample"; // 追加することで<Sample />が利用できる function App() { return ( <div className="App"> <header className="App-header"> <img src={logo} className="App-logo" alt="logo" /> <p> Edit <code>src/App.js</code> and save to reload. </p> <a className="App-link" href="https://reactjs.org" target="_blank" rel="noopener noreferrer" > Learn React </a> <Sample /> </header> </div> ); } export default App; ブラウザを起動して、http://localhost:3000/ を表示するとPOSTボタンが追加されていることが確認できます。 POSTボタンをクリックするとFastAPIにPOSTリクエストを送り、応答を画面に表示します。 おわりに dockerの操作はターミナルでのCUI操作が多めになって、初心者向けじゃないと思っていたので、Visual Stusio Codeの拡張機能を利用したGUI操作で説明を記載してみました。 本来はターミナルでdockerコマンドを利用するべきですので、慣れてきたらdockerコマンドを覚えてください。 Reactは、サンプル実行したくらいなのであまり理解が深まっていません。 次回は、こちらで解説したマインスイーパを作ることで理解を深める記事の予定です。