本記事の概要 PythonによるWebアプリケーション学習ロードマップのStep2として、Step1で作成したWebサーバおよびAppサーバをDockerコンテナにて起動するように設定する手順について記載していきます。 記事は前・後編の2編での構成となり、 前編:Docker化後編：docker-compose導入 についての記載となります。 前提 MacOSをホストPCとして利用することを想定したコマンド表記となります。 ホストPCとしての準備 本記事ではローカルPCをDockerのホストPCとして構築していきます。 これにあたりDockerを動かすための準備が必要です。 いくつかの方法がありますが、MacOSの場合はDocker for Macをbrewインストールするのが手っ取り早いと思います。 Terminal brew cask install docker これでアプリケーションがインストールされるので、ローカルでDocker.appを起動します。右上にクジラのようなアイコンが出現して、下記のようにRunningになっていれば完了です。 最終的な成果物 イメージ図 ソースコード Githubリポジトリを参照ください。 ソースコード簡易解説 Dockerコンテナ化にあたって、Step1からの主な変更点は以下の2つです。 Webサーバ、AppサーバそれぞれのDockerfileを新規作成 起動コマンドを記載したMakefileを新規作成 このうち、2つめのMakefileについては、dockerコマンドの入力を簡易的にするだけのものであり、本質的な追加は1つめのDockerfileになります。それぞれのDockerfileの内容について見ていきたいと思います。(Dockerfileそのものについては後述) Webサーバ Dockerfile # ベースとなるイメージを指定。この場合はバージョンまで特定のタグを指定している。 FROM nginx:1.17.6-alpine # ホストPCの設定ファイル(config/nginx.conf)を上で作成したディレクトリへコピーして送る RUN mkdir -p /etc/nginx COPY config/nginx.conf /etc/nginx/nginx.conf 単にnginxを利用するのであれば、Docker Hubに公開されているnginx Official ImageをpullするだけでOKです。今回は手元で作成したnginx設定ファイルを読んで起動させたいので、次のような作業を行っています。 ベースとなるイメージを指示 自前の設定ファイルを送るパスを作成 自前の設定ファイルをホストPCから、このイメージへコピー Appサーバ Dockerfile # 今回はdebianベースのpythonイメージをベースとする FROM python:3.8-slim-buster # 設定ファイルの転送(適当な場所が思いつかないので/app直下) RUN mkdir -p /app/config COPY requirements.txt /app/requirements.txt COPY config/gunicorn_settings.py /app/config/gunicorn_settings.py COPY flask_app.py /app/flask_app.py # パッケージのインストール RUN pip install -r /app/requirements.txt EXPOSE 9876 WORKDIR /app # run実行時のコマンド # ENTRYPOINT->CMDでCMDはrunのときの引数で上書きすることが可能 ENTRYPOINT [ "gunicorn", "flask_app:app" ] CMD [ "-c", "/app/config/gunicorn_settings.py" ] osのみのベースイメージから始めて、python等をインストールするという手順でもいいのですが、せっかくpythonのOfficialイメージが公開されているので、今回はこれをベースとしてスタートします。 パッケージのインストールまではほぼWebサーバと同様ですが、それより下はWebサーバにはなかった記述ですね。次のようなことをしています。 Appサーバのコンテナで、9876ポートをLISTEN状態とする コンテナ起動時のベースディレクトリを/appに設定する コンテナ起動時、gunicorn flask_app:app -c /app/config/gunicorn_settings.pyコマンドを実行する About Docker Docker化する理由 これに関してはいくつかあると思いますが、自分の感じる利点を２つ記載しておきます。 開発/実行環境の統一・準備の簡易化 チーム開発を行うにあたって、これまでは開発者がそれぞれのマシンで開発環境を準備してそのうえで開発を開始する必要がありました。手順を示したドキュメントはあるでしょうが、実際はドキュメント不備やツールのアップデートなどの事由によってうまく環境構築ができないなどコストがかかるかと思います。また、個人がそれぞれに言語のバージョンアップなどを行い微妙な違いが発生するというリスクも考えられます。 一方で、あらかじめ用意されたDockerコンテナを利用することにより、 少ないコマンド数(docker run)で環境が構築できる 開発環境の統一が容易 という恩恵を受けることができます。 本番環境にもコンテナをのせられる クラウド上での運用が当たり前となった現在では、GKEなどを利用したコンテナオーケストレーションツールが数多く出回っています。コンテナオーケストレーションというくらいなので、実際に本番環境でもコンテナ上でアプリケーションが起動していることとなります。 もちろん開発、ステージング、本番とで環境変数やエンドポイントなどを変更することが必要ですが、オーケストレーション側でも吸収することはでき、いずれにせよ開発環境で動いたコンテナがほぼそのまま本番環境でも稼働することとなります。 イメージとコンテナ まずイメージを作成(=ビルド)して、そのイメージをもとにコンテナを作成・起動するといった順番です。 うまい例ではないですが、PCゲームで置き換えると - Dockerイメージ = ディスク - Dockerコンテナ = ゲーム起動中のウィンドウ みたいな感じです。 Docker Hubとは 自身が作成したコンテナイメージをアップロードして公開・共有できるサービス。要はGithubのDocker限定版みたいなものです。 公開されているイメージは自由にダウンロード、利用することが可能です。自身でカスタマイズしたイメージを作成する際にも、ベースとなるイメージはDocker Hubに登録されているものから選択します。 イメージの信頼性 Docker Hubには有志によるイメージも数多く登録されています。その中でベースイメージとして選択するとよいものはDocker Official Imagesというタグのついたものとなります。 理由を一言にすると、信頼性が高いからなのですが、いくつか箇条書きであげておきます。 適時セキュリティ・アップデートが行われる 明確なドキュメントが存在する Dockerfileのベストプラクティスを提供する 必要不可欠なベースイメージを提供する Dockerfileとは 作成するコンテナのベースとなるイメージ、アプリケーションインストール、アプリケーション起動の準備などの一連の作業を一括で実施できる命令が記述されたファイルのことです。 なお、Dockerfileの記述に関する詳細はこちらを参照ください。
PythonによるWebアプリケーション学習ロードマップのStep2として、Step1で作成したWebサーバおよびAppサーバをDockerコンテナにて起動するように設定する手順について記載していきます。 記事は前・後編の2編での構成となり、 前編:Docker化後編：docker-compose導入 についての記載となります。
前編:Docker化
後編：docker-compose導入
MacOSをホストPCとして利用することを想定したコマンド表記となります。
MacOS
本記事ではローカルPCをDockerのホストPCとして構築していきます。 これにあたりDockerを動かすための準備が必要です。 いくつかの方法がありますが、MacOSの場合はDocker for Macをbrewインストールするのが手っ取り早いと思います。
Docker for Mac
brew cask install docker
これでアプリケーションがインストールされるので、ローカルでDocker.appを起動します。右上にクジラのようなアイコンが出現して、下記のようにRunningになっていれば完了です。
Docker.app
Githubリポジトリを参照ください。
Dockerコンテナ化にあたって、Step1からの主な変更点は以下の2つです。
このうち、2つめのMakefileについては、dockerコマンドの入力を簡易的にするだけのものであり、本質的な追加は1つめのDockerfileになります。それぞれのDockerfileの内容について見ていきたいと思います。(Dockerfileそのものについては後述)
# ベースとなるイメージを指定。この場合はバージョンまで特定のタグを指定している。 FROM nginx:1.17.6-alpine # ホストPCの設定ファイル(config/nginx.conf)を上で作成したディレクトリへコピーして送る RUN mkdir -p /etc/nginx COPY config/nginx.conf /etc/nginx/nginx.conf
単にnginxを利用するのであれば、Docker Hubに公開されているnginx Official ImageをpullするだけでOKです。今回は手元で作成したnginx設定ファイルを読んで起動させたいので、次のような作業を行っています。
Docker Hub
# 今回はdebianベースのpythonイメージをベースとする FROM python:3.8-slim-buster # 設定ファイルの転送(適当な場所が思いつかないので/app直下) RUN mkdir -p /app/config COPY requirements.txt /app/requirements.txt COPY config/gunicorn_settings.py /app/config/gunicorn_settings.py COPY flask_app.py /app/flask_app.py # パッケージのインストール RUN pip install -r /app/requirements.txt EXPOSE 9876 WORKDIR /app # run実行時のコマンド # ENTRYPOINT->CMDでCMDはrunのときの引数で上書きすることが可能 ENTRYPOINT [ "gunicorn", "flask_app:app" ] CMD [ "-c", "/app/config/gunicorn_settings.py" ]
osのみのベースイメージから始めて、python等をインストールするという手順でもいいのですが、せっかくpythonのOfficialイメージが公開されているので、今回はこれをベースとしてスタートします。 パッケージのインストールまではほぼWebサーバと同様ですが、それより下はWebサーバにはなかった記述ですね。次のようなことをしています。
パッケージのインストール
/app
gunicorn flask_app:app -c /app/config/gunicorn_settings.py
これに関してはいくつかあると思いますが、自分の感じる利点を２つ記載しておきます。
チーム開発を行うにあたって、これまでは開発者がそれぞれのマシンで開発環境を準備してそのうえで開発を開始する必要がありました。手順を示したドキュメントはあるでしょうが、実際はドキュメント不備やツールのアップデートなどの事由によってうまく環境構築ができないなどコストがかかるかと思います。また、個人がそれぞれに言語のバージョンアップなどを行い微妙な違いが発生するというリスクも考えられます。 一方で、あらかじめ用意されたDockerコンテナを利用することにより、
docker run
という恩恵を受けることができます。
クラウド上での運用が当たり前となった現在では、GKEなどを利用したコンテナオーケストレーションツールが数多く出回っています。コンテナオーケストレーションというくらいなので、実際に本番環境でもコンテナ上でアプリケーションが起動していることとなります。 もちろん開発、ステージング、本番とで環境変数やエンドポイントなどを変更することが必要ですが、オーケストレーション側でも吸収することはでき、いずれにせよ開発環境で動いたコンテナがほぼそのまま本番環境でも稼働することとなります。
まずイメージを作成(=ビルド)して、そのイメージをもとにコンテナを作成・起動するといった順番です。 うまい例ではないですが、PCゲームで置き換えると - Dockerイメージ = ディスク - Dockerコンテナ = ゲーム起動中のウィンドウ みたいな感じです。
自身が作成したコンテナイメージをアップロードして公開・共有できるサービス。要はGithubのDocker限定版みたいなものです。 公開されているイメージは自由にダウンロード、利用することが可能です。自身でカスタマイズしたイメージを作成する際にも、ベースとなるイメージはDocker Hubに登録されているものから選択します。
Docker Hubには有志によるイメージも数多く登録されています。その中でベースイメージとして選択するとよいものはDocker Official Imagesというタグのついたものとなります。 理由を一言にすると、信頼性が高いからなのですが、いくつか箇条書きであげておきます。
Docker Official Images
作成するコンテナのベースとなるイメージ、アプリケーションインストール、アプリケーション起動の準備などの一連の作業を一括で実施できる命令が記述されたファイルのことです。
なお、Dockerfileの記述に関する詳細はこちらを参照ください。
はじめに Pipenvを用いた仮想環境上でDjangoを起動させます。 Pipenvを用いた仮想環境上にDjangoを配置することでDockerやチーム開発でのビルドが常に同じ結果となり、開発がスムーズになります。複数人やDockerを用いた開発でのベストプラクティスと考えています。 本記事はDjangoアプリをDocker上に構築しAWS Fargateにデプロイするプロジェクトの一部です。 pipenvのインストール pipを用いてpipenvをインストールします。 $ pip install pipenv 仮想環境上にDjangoをインストールする pipenvをインストール後、デスクトップでhelloディレクトリを作成、helloディレクトリに移動します。 $ cd ~/Desktop $ mkdir hello && cd hello Pipenvコマンドを使用して仮想環境上にDjangoをインストールします。 $ pipenv install django==2.2.3 実行後、PipfileとPipfile.lockファイルが作成されます。 Pipfileにはインストールするライブラリ名とバージョンが記録されます。 Pipfile.lockには実際にインストールされたライブラリの情報が記録されます。 $ ls Pipfile Pipfile.lock 仮想環境に入り、startprojectコマンドを実行し新しいDjangoプロジェクトを作成します。ピリオドを忘れずに。 $ pipenv shell (hello)$ django-admin startproject hello_project . マイグレートを実施してデータベースの初期化を実行し、Django開発用サーバーを起動します。 (hello)$ python manage.py migrate (hello)$ python manage.py runserver http://127.0.0.1:8000/ にブラウザでアクセスするとDjangoのwelcomeページが表示されています。これにより仮想環境上でDjangoを立ち上がっていることが確認できました。
Pipenvを用いた仮想環境上でDjangoを起動させます。
Pipenvを用いた仮想環境上にDjangoを配置することでDockerやチーム開発でのビルドが常に同じ結果となり、開発がスムーズになります。複数人やDockerを用いた開発でのベストプラクティスと考えています。
本記事はDjangoアプリをDocker上に構築しAWS Fargateにデプロイするプロジェクトの一部です。
pipを用いてpipenvをインストールします。
$ pip install pipenv
pipenvをインストール後、デスクトップでhelloディレクトリを作成、helloディレクトリに移動します。
$ cd ~/Desktop $ mkdir hello && cd hello
Pipenvコマンドを使用して仮想環境上にDjangoをインストールします。
$ pipenv install django==2.2.3
実行後、PipfileとPipfile.lockファイルが作成されます。 Pipfileにはインストールするライブラリ名とバージョンが記録されます。 Pipfile.lockには実際にインストールされたライブラリの情報が記録されます。
$ ls Pipfile Pipfile.lock
仮想環境に入り、startprojectコマンドを実行し新しいDjangoプロジェクトを作成します。ピリオドを忘れずに。
$ pipenv shell (hello)$ django-admin startproject hello_project .
マイグレートを実施してデータベースの初期化を実行し、Django開発用サーバーを起動します。
(hello)$ python manage.py migrate (hello)$ python manage.py runserver
http://127.0.0.1:8000/ にブラウザでアクセスするとDjangoのwelcomeページが表示されています。これにより仮想環境上でDjangoを立ち上がっていることが確認できました。
$ git clone https://github.com/newsdict/docker_rust $ cp env-example .env $ docker-compose build $ docker-compose up $ wget localhost:3000
はじめに Dockerなどのコンテナを使っていると「SELinuxを有効にしておけ」と言われますが、 実際に起動していないとどうなのか検証してみたことと、 色々なところでも紹介されているものですが、自身のメモとして投稿しました。 今回の検証環境 VirtualBox 6.0 CentOS 7.3 Docker 19.03.05 SELinuxが無効な場合 まず、SELinuxを無効にします。 # vi /etc/selinux/config (以下にパラメータを変更) SELINUX=disabled # enforcingからdisabledに変更 # reboot ※ SELinuxの状態 Enforcing : SELinuxが有効 Permissive ： SELinuxのラベリングはしているけど、無効な状態 Disabled ： SELinuxが無効 再起動後、SELinuxの状態確認 # getenforce Disabled これでコンテナを作成してみて、dmesgコマンドを実行すると、 $ docker run -it --rm centos:7 bash [root@27726ede260a /]# dmesg (実行結果は省略) と色々出てきてしまいます。 これはなんでかと調べると、コンテナはホストOSのカーネルを共有しているため、 dmesgなどのコマンド実行するとすべて中身が見えてしまいます。 コンテナを安全に設計していたとしてもホストOS側が雑に作られていると、 ホストOSが攻撃対象になってしまうことが想定されています。 それとコンテナの脆弱性に関しては少しずつ発表されてきていますが、 コンテナは最悪作り直しがすぐにできますが、 ホスト側の作り直しはかなり手間なので、SELinuxを有効にしておく必要があります。 SELinuxが有効な場合 まず、SELinuxを有効にします。 # vi /etc/selinux/config (以下にパラメータを変更) SELINUX=enforcing # disabledからenforcingに変更 # reboot (再起動後確認) # getenforce Enforcing ではコンテナを作成し、dmesgコマンドを入力すると以下の結果になりました。 $ docker run -it --rm centos:7 bash [root@c282a2fe3617 /]# dmesg dmesg: read kernel buffer failed: Operation not permitted エラーになり、dmesgコマンドが失敗しました。 このようにホスト側の情報を隠すといううえでも、SELinuxを有効にする必要があります。 いったんコンテナを抜けてラベルを確認します。 [root@c282a2fe3617 /]# (Ctrl +P→Q) $ $ ps -efZ (一部省略) system_u:system_r:spc_t:s0 root 3084 3068 0 15:06 pts/0 00:00:00 bash $ ls -Z -rw-r--r--. root root system_u:object_r:var_log_t:s0 /var/log/dmesg 補足 DockerのSELinuxに関しては、別パッケージが必要です。 最新版はcontainer-selinuxパッケージにSELinuxの必要なラベルが入っており、インストール時もdocker-ceなどのパッケージと依存関係にあるのでセットでインストールします。 古いDockerのバージョンですと、docker-selinuxパッケージが別途必要なようです。 新しくDockerをインストールするなら、最新バージョンのほうが良さそうですね。 脆弱性も発表されていますし。。 参考: Dockerの脆弱性 Dockerの探索 (参考)dmesgのアクセス制限 コンテナ上でdmesgコマンドを実行してもエラーになるように、専用の個別設定も可能ですが、 一つ一つ設定していくのは手間なので、SELinuxでまとめて制限かけたほうが無難な印象です。 # echo "kernel.dmesg_restrict=1" >> /etc/sysctl.d/dmesg.conf # sysctl --system $ $ docker run -it --rm centos:7 bash /# dmesg dmesg: read kernel buffer failed: Operation not permitted さいごに このように、コンテナやクラウド、さらにはIoTなど、LinuxをホストOSとして利用されていることが増えてきましたが、 リソースが乏しく、ソフトのバージョンアップなどが難しいものなどで使用される場合は万が一侵入されても大丈夫な対策として、SELinuxの導入がされ始めています。 先述していますが、個別設定でも抜けがでたりするので、まとめて設定できるSELinuxに慣れないといけないのだな…と私は感じました。 参考になれば幸いです。
Dockerなどのコンテナを使っていると「SELinuxを有効にしておけ」と言われますが、 実際に起動していないとどうなのか検証してみたことと、 色々なところでも紹介されているものですが、自身のメモとして投稿しました。
まず、SELinuxを無効にします。
# vi /etc/selinux/config (以下にパラメータを変更) SELINUX=disabled # enforcingからdisabledに変更 # reboot
※ SELinuxの状態
再起動後、SELinuxの状態確認
# getenforce Disabled
これでコンテナを作成してみて、dmesgコマンドを実行すると、
$ docker run -it --rm centos:7 bash [root@27726ede260a /]# dmesg (実行結果は省略)
と色々出てきてしまいます。 これはなんでかと調べると、コンテナはホストOSのカーネルを共有しているため、 dmesgなどのコマンド実行するとすべて中身が見えてしまいます。
コンテナを安全に設計していたとしてもホストOS側が雑に作られていると、 ホストOSが攻撃対象になってしまうことが想定されています。 それとコンテナの脆弱性に関しては少しずつ発表されてきていますが、 コンテナは最悪作り直しがすぐにできますが、 ホスト側の作り直しはかなり手間なので、SELinuxを有効にしておく必要があります。
まず、SELinuxを有効にします。
# vi /etc/selinux/config (以下にパラメータを変更) SELINUX=enforcing # disabledからenforcingに変更 # reboot (再起動後確認) # getenforce Enforcing
ではコンテナを作成し、dmesgコマンドを入力すると以下の結果になりました。
$ docker run -it --rm centos:7 bash [root@c282a2fe3617 /]# dmesg dmesg: read kernel buffer failed: Operation not permitted
エラーになり、dmesgコマンドが失敗しました。 このようにホスト側の情報を隠すといううえでも、SELinuxを有効にする必要があります。
いったんコンテナを抜けてラベルを確認します。
[root@c282a2fe3617 /]# (Ctrl +P→Q) $ $ ps -efZ (一部省略) system_u:system_r:spc_t:s0 root 3084 3068 0 15:06 pts/0 00:00:00 bash $ ls -Z -rw-r--r--. root root system_u:object_r:var_log_t:s0 /var/log/dmesg
DockerのSELinuxに関しては、別パッケージが必要です。 最新版はcontainer-selinuxパッケージにSELinuxの必要なラベルが入っており、インストール時もdocker-ceなどのパッケージと依存関係にあるのでセットでインストールします。 古いDockerのバージョンですと、docker-selinuxパッケージが別途必要なようです。 新しくDockerをインストールするなら、最新バージョンのほうが良さそうですね。 脆弱性も発表されていますし。。 参考: Dockerの脆弱性 Dockerの探索
コンテナ上でdmesgコマンドを実行してもエラーになるように、専用の個別設定も可能ですが、 一つ一つ設定していくのは手間なので、SELinuxでまとめて制限かけたほうが無難な印象です。
# echo "kernel.dmesg_restrict=1" >> /etc/sysctl.d/dmesg.conf # sysctl --system $ $ docker run -it --rm centos:7 bash /# dmesg dmesg: read kernel buffer failed: Operation not permitted
このように、コンテナやクラウド、さらにはIoTなど、LinuxをホストOSとして利用されていることが増えてきましたが、 リソースが乏しく、ソフトのバージョンアップなどが難しいものなどで使用される場合は万が一侵入されても大丈夫な対策として、SELinuxの導入がされ始めています。
先述していますが、個別設定でも抜けがでたりするので、まとめて設定できるSELinuxに慣れないといけないのだな…と私は感じました。
参考になれば幸いです。
AMD Ryzen5 系列のCPUを使っている方でdockerがインストールできないという方へ AMD Ryzen 5 のPCを使っていると不便なことが多々ある。 Linux(Ubuntu18.04)をインストールした時も、適切なドライバーが提供されておらず、やけに重たくなるなどとということがあった。 dockerをインストールする際にも問題は訪れた。 まず、僕の使っているPCはWindows Homeであるために、dockerを入れる際にもVirtualBoxを導入する必要がある。ハイパーバイザーが不要であることが魅力であったdockerでvirtualBoxが必要とされることは少し悲しいが、仕方がない。 しかし、問題はまだある。 いざ、Docker Toolboxをインストールしようとした際に、以下のようなエラーが表れた。 Error with pre-create check: "This computer doesn't have VT-X/AMD-v enabled. Enabling it in the BIOS is mandatory" 訳すと、「virtual machinを有効にするっていう設定が出来てないよ。BIOSで設定して出直して来な！」とのことである。 しかし、BIOSで設定を確認しても仮想環境の利用は有効になっている。VirtualBoxも普通に動くし、何かおかしいな。と思っていたら以下の記事で同じ境遇の方を見つけた。 AMD RyzenのWindowsでDocker Toolboxを動かすとCPU仮想化エラーが発生する この方によると、Docker Toolbox 18.03 であれば上手くいくらしい。 ここからDockerToolbox18.03.exeをインストールした。 その結果、上手くDockerをインストールすることが出来た。 さいごに 上記記事によって何とかインストール出来た。 執筆者に感謝します。
AMD Ryzen 5 のPCを使っていると不便なことが多々ある。 Linux(Ubuntu18.04)をインストールした時も、適切なドライバーが提供されておらず、やけに重たくなるなどとということがあった。
dockerをインストールする際にも問題は訪れた。 まず、僕の使っているPCはWindows Homeであるために、dockerを入れる際にもVirtualBoxを導入する必要がある。ハイパーバイザーが不要であることが魅力であったdockerでvirtualBoxが必要とされることは少し悲しいが、仕方がない。
しかし、問題はまだある。 いざ、Docker Toolboxをインストールしようとした際に、以下のようなエラーが表れた。
Error with pre-create check: "This computer doesn't have VT-X/AMD-v enabled. Enabling it in the BIOS is mandatory"
訳すと、「virtual machinを有効にするっていう設定が出来てないよ。BIOSで設定して出直して来な！」とのことである。
しかし、BIOSで設定を確認しても仮想環境の利用は有効になっている。VirtualBoxも普通に動くし、何かおかしいな。と思っていたら以下の記事で同じ境遇の方を見つけた。
AMD RyzenのWindowsでDocker Toolboxを動かすとCPU仮想化エラーが発生する
この方によると、Docker Toolbox 18.03 であれば上手くいくらしい。 ここからDockerToolbox18.03.exeをインストールした。
その結果、上手くDockerをインストールすることが出来た。
上記記事によって何とかインストール出来た。 執筆者に感謝します。
AMD Ryzen5 系列のCPUを使っている方でdockerがインストールできないという方へ AMD Ryzen 5 のPCを使っていると不便なことが多々ある。 Linux(Ubuntu18.04)をインストールした時も、適切なドライバーが提供されておらず、やけに重たくなるなどとということがあった。 dockerをインストールする際にも問題は訪れた。 まず、僕の使っているPCはWindows10 Homeであるために、dockerを入れる際にもVirtualBoxを導入する必要がある。ハイパーバイザーが不要であることが魅力であったdockerでvirtualBoxが必要とされることは少し悲しいが、仕方がない。 しかし、問題はまだある。 いざ、Docker Toolboxをインストールしようとした際に、以下のようなエラーが表れた。 Error with pre-create check: "This computer doesn't have VT-X/AMD-v enabled. Enabling it in the BIOS is mandatory" 訳すと、「virtual machinを有効にするっていう設定が出来てないよ。BIOSで設定して出直して来な！」とのことである。 しかし、BIOSで設定を確認しても仮想環境の利用は有効になっている。VirtualBoxも普通に動くし、何かおかしいな。と思っていたら以下の記事で同じ境遇の方を見つけた。 AMD RyzenのWindowsでDocker Toolboxを動かすとCPU仮想化エラーが発生する この方によると、Docker Toolbox 18.03 であれば上手くいくらしい。 ここからDockerToolbox18.03.exeをインストールした。 その結果、上手くDockerをインストールすることが出来た。 さいごに 上記記事によって何とかインストール出来た。 執筆者に感謝します。
dockerをインストールする際にも問題は訪れた。 まず、僕の使っているPCはWindows10 Homeであるために、dockerを入れる際にもVirtualBoxを導入する必要がある。ハイパーバイザーが不要であることが魅力であったdockerでvirtualBoxが必要とされることは少し悲しいが、仕方がない。
コード 下記のコマンドを指定して完了。 /mygit/appdir/は実行したいpythonファイルが有るフォルダを指定してください。 docker run -it --rm --name pythoncv -w /mygit/appdir/ -v "$PWD":/mygit/appdir/ jjanzic/docker-python3-opencv python index.py 各オプション -w 作業フォルダ指定 -v マウントディレクトリ指定 "is not shared from OS X and is not known to Docker."というエラーが出る場合があります。 こちらの記事を参照して回避してください。 【Docker For Mac】Error response from daemon: Mounts deniedの対応 https://qiita.com/nishina555/items/a75ce530d9382aa09511 感想 環境構築で時間が取られなくて最高。
下記のコマンドを指定して完了。 /mygit/appdir/は実行したいpythonファイルが有るフォルダを指定してください。
/mygit/appdir/
docker run -it --rm --name pythoncv -w /mygit/appdir/ -v "$PWD":/mygit/appdir/ jjanzic/docker-python3-opencv python index.py
作業フォルダ指定
マウントディレクトリ指定
"is not shared from OS X and is not known to Docker."というエラーが出る場合があります。 こちらの記事を参照して回避してください。
【Docker For Mac】Error response from daemon: Mounts deniedの対応 https://qiita.com/nishina555/items/a75ce530d9382aa09511
環境構築で時間が取られなくて最高。
はじめに ちょうど1年ほど前に「procs：新しいプロセス表示・検索ツール」の初期バージョンを公開しました。その後54回のリリースを経て、昨日v0.9.0になりました。 ちょうどきりがいいのでこの1年間のアップデート内容をまとめて紹介します。 特徴 procsはpsコマンドの代替となるプロセス一覧の表示ツールです。主な特徴は以下の通りです。 色・単位付きの表示 キーワードによる絞り込み psで表示できないカラムに対応 TCP/UDPポート ディスクのRead/Write速度 Dockerコンテナ名 ページャ対応 topのような定期更新モード ツリービュー アップデート Linux版の大幅な高速化 これは高速化を頑張ったというより異常に遅い箇所を見過ごしていたものです。最近気づいて修正したところ10倍ほど高速化しました。 体感できるレベルの差があるので、古いバージョンをご利用の方は最新版へのアップデートをお願いします。 macOS/Windows対応 初期リリースではLinuxのみ対応でしたが、macOSとWindowsにも対応しました。ただしLinux版より表示できるカラムが若干少なくなっています。 各種パッケージ提供 いくつかのパッケージマネージャに対応して簡単にインストールできるようになりました。 Nixpkgs snapcraft homebrew Alpine Linux Cargo 具体的なコマンドはこちらにまとまっています。 新しいカラム psに存在しないカラムをいろいろ追加しました。一覧はこちら。 個人的にはDockerコンテナ名表示をよく使っています。 ページャ対応 出力をページャ（デフォルトはless）に通すようにしたので狭い画面でもスクロールするなどして見やすくなりました。 パイプを通す場合は自動で無効化されます。 定期更新モード topコマンドのように定期更新されるモードを追加しました。 procs -w 10で10秒ごとに更新されます。 キー入力でソートするカラムを変更できることもできます。 ツリービュー プロセスの依存関係をツリーで表示することができます。
ちょうど1年ほど前に「procs：新しいプロセス表示・検索ツール」の初期バージョンを公開しました。その後54回のリリースを経て、昨日v0.9.0になりました。 ちょうどきりがいいのでこの1年間のアップデート内容をまとめて紹介します。
procsはpsコマンドの代替となるプロセス一覧の表示ツールです。主な特徴は以下の通りです。
これは高速化を頑張ったというより異常に遅い箇所を見過ごしていたものです。最近気づいて修正したところ10倍ほど高速化しました。 体感できるレベルの差があるので、古いバージョンをご利用の方は最新版へのアップデートをお願いします。
初期リリースではLinuxのみ対応でしたが、macOSとWindowsにも対応しました。ただしLinux版より表示できるカラムが若干少なくなっています。
いくつかのパッケージマネージャに対応して簡単にインストールできるようになりました。
具体的なコマンドはこちらにまとまっています。
psに存在しないカラムをいろいろ追加しました。一覧はこちら。 個人的にはDockerコンテナ名表示をよく使っています。
出力をページャ（デフォルトはless）に通すようにしたので狭い画面でもスクロールするなどして見やすくなりました。 パイプを通す場合は自動で無効化されます。
topコマンドのように定期更新されるモードを追加しました。 procs -w 10で10秒ごとに更新されます。 キー入力でソートするカラムを変更できることもできます。
procs -w 10
プロセスの依存関係をツリーで表示することができます。
