- 投稿日：2020-02-06T23:33:42+09:00
Elasticsearch 7.5 と Kibana 7.5 に Security を有効化してDockerで起動する（コピペ）
やりたいこと
ログの集計・可視化をElasticsearchとKibanaを使って行いたいと思い、色々調べてみたところ、どうやらAmazon Lightsailで動かすのが安そうということで、環境構築について検討した。
Elastic Cloudだと手軽に始められる反面、インスタンスコストが割高で、最小構成だとリサイズに失敗したりしてほとんど何もできなかった。
Lightsailの場合、4GB RAMのインスタンスが$20/月なので、2GBをElasticsearchに、1GBをKibanaに、という構成ができそう。
そして、比較的最近、無償ライセンスのBasicプランでもX-Pack Securityが使えるようになっているので、しっかり認証も付けておきたい。（Lightsailはポート制限しかできない）
開発はMacで行うので、できればローカルの開発環境と本番を同じように構成したい。要点
- Elasticsearch & Kibana を使う
- X-Pack Securityを有効化する
- なるべく安くそこそこの環境を整えたい
- MacとLightsailで同じ環境を作りたい
前提
- Dockerが使える状態
- ホスト側がRAM 4GB以上で、Elasticsearchに2GB、Kibanaに1GBを割当てられる
- 直近ではSSLオプション使わない
以下をコピペしとけば動く
1. データの保存先を作成
- 必要に応じて権限を変える
mkdir -p ~/Development/Docker/Elasticsearch/data ~/Development/Docker/Elasticsearch/certs2. Elasticsearchを起動
- 環境変数
ELASTIC_PASSWORDがelasticユーザーのパスワードなので変更するdocker run --name Elasticsearch -d \ -m 2048m \ -p 9200:9200 \ -p 9300:9300 \ -e cluster.name=ES \ -e discovery.type=single-node \ -e network.host=0.0.0.0 \ -e bootstrap.memory_lock=true \ -e xpack.security.enabled=true \ -e xpack.monitoring.collection.enabled=true \ -e "ES_JAVA_OPTS=-Xms1024m -Xmx1024m" \ -e "ELASTIC_PASSWORD=iY69DxipKifV7utYA4t6jgxT" \ -v ~/Development/Docker/Elasticsearch/data:/usr/share/elasticsearch/data \ -v ~/Development/Docker/Elasticsearch/certs:/usr/share/elasticsearch/certs \ --ulimit nproc=4096:4096 \ --ulimit memlock=256000:256000 \ --ulimit nofile=65536:65536 \ docker.elastic.co/elasticsearch/elasticsearch:7.5.23. kibanaユーザーのパスワードを設定する
- BASIC認証のパスワードは2で指定したものを使う
passwordの値がkibanaユーザーのパスワードcurl -XPUT --user elastic:iY69DxipKifV7utYA4t6jgxT 'localhost:9200/_xpack/security/user/kibana/_password' -H "Content-Type: application/json" -d '{ "password" : "6ezji8D5jvceXUsTsvg8mAY4" }'4. Kibanaを起動する
ELASTICSEARCH_PASSWORDは3で設定したkibanaユーザーのパスワードを指定するdocker run --name Kibana -d \ --link Elasticsearch:elasticsearch \ -m 1024m \ -p 5601:5601 \ -e "ELASTICSEARCH_HOSTS=http://elasticsearch:9200" \ -e "ELASTICSEARCH_USERNAME=kibana" \ -e "ELASTICSEARCH_PASSWORD=6ezji8D5jvceXUsTsvg8mAY4" \ --ulimit nproc=4096:4096 \ --ulimit memlock=256000:256000 \ --ulimit nofile=65536:65536 \ docker.elastic.co/kibana/kibana:7.5.24. 諸々設定する
- ブラウザでホストの
5601番ポートに接続elasticユーザーとしてログイン- グループやユーザーを作成
セキュリティを強化する
SSLオプションを使いましょう。
セキュリティ機能のはじめ方 | Elastic Blog
- 投稿日：2020-02-06T23:04:02+09:00
Julia の Jupyter Notebook を他人に試してもらうためのツールとして Binder を活用する
本日は
Julia は Python に比べるとまだ人口が少ないので「こういうのをJuliaで作ったよ！」とSNSで宣伝するとみんな（Julia界隈）が喜びます．作ったらそれがSOTA(state of the art) なんです．ただし，動かす側からだとそのスクリプト，ノートブックを動かすのにそれをダウンロードして必要に応じてJupyter Notebookを立ち上げるという一手間が肉に塩を振る以上に手間がかかってしまうことです．環境を構築している間にSNSで動いてる！しゅごいいぃと感じた熱意が指数関数的に現象してしまいます．パッケージが入ってなくて途中でエラーを吐いて動かなくなったら尚更です．また，閲覧しているデバイスがパソコンとは限らないので可能ならスマホ，タブレットでみたユーザーがパソコンにログインして動かすというのも手間っちゃ手間です．
さて，グラフ描画ライブラリの Julia ラッパーを提供する GR.jl 開発者のツイートでこういうのがありました．
By popular demand from the #JuliaLang community, binary packages for #raspberrypi and #archlinux are now available for GR. The new features include the drawing of composite paths (arcs, Bézier curves, etc.) as well as marker symbols with borders. See https://t.co/jiK0sL5IOO
— Josef Heinen (@josef_heinen) January 28, 2020リンクをクリックするとbinderというアイコンが出てきて
Jupyter Notebook が見つかって
anim.ipynb を選択して動かすと
動くんですけど！！！，マジかブラウザ上でJulia動かせるんか！ iPhone や iPad で動くんか！(実際に動きます).
ということで
- Binder の使い方を紹介します．Binderを使うと既存の公開されているリポジトリにあるJupyter Notebookをブラウザ上で動かすことができます．
- Julia に限らずPythonやRといった言語も活用できるようです．例えば ipywidgets のnotebook形式のドキュメント などもbinderを立ち上げて利用することができます．例えばhttps://github.com/jupyter-widgets/ipywidgets にある
launch binderのアイコンをクリックすることでPythonの環境が立ち上がり，そこで動かすことができます．基本的な使い方（利用する側として）
まず，どういうことができるのかを体感するために利用する立場としてBinderを触ってみましょう．
mybinder にアクセス
https://mybinder.org/ にアクセスします．下記の図のような画面で次の要素を指定します．
- 動かしたいノートブックが置いてあるGitHubのリポジトリ
- 対応するブランチ(基本masterで良い)
- リポジトリを起点としたノートブックの置いてあるパスを指定（指定しなければリポジトリ全体をブラウザ上で見渡すことができる）
launch ボタンを押してしばらく待つと環境が立ち上がります．環境はDockerのコンテナが動くようです．動かしたいリポジトリが有名であれば誰かがイメージをビルドしているので（Binderが溜めている？）キャッシュを利用して環境が立ち上がります．個人開発者のこじんまりしているものであればイメージのビルドが走るログが流れるのでコーヒーを淹れながら待ちましょう．
変換できるリポジトリ
- Configuration Files の項目を見るとリポジトリのルートに
setup.py,requirements.txtがあれば Python の環境をBinderが用意するようです．Project.tomlがあればJuliaの環境を用意するようです．あとで紹介しますが，Dockerfileがあればそのファイルをビルドするようです．In the majority of cases, providing your own Dockerfile is not necessary as the base images provide core functionality, compact image sizes, and efficient builds. We recommend trying the other configuration files before deciding to use your own Dockerfile.
このようにリポジトリのルートにある設定ファイルを認識するようです．もし，リポジトリに
binderというディレクトリがあれば Binder がBinder用の設定ファイルとして認識するようですね．これは開発する側から見ると共有に必要な設定を記述する設定ファイルと開発用の設定ファイルを区別するために役に立ちそうです．参考: FAQ
Yes! Configuration files may be placed in the root of your repository or in a binder/ folder in the root of your repository (i.e. myproject/binder/). If a binder/ folder is used, Binder will only read configuration files from that location (i.e. myproject/binder/requirements.txt) and will ignore those in the repository’s root (myproject/environment.yml and myproject/requirements.txt).
- もしリポジトリのメンテナーがBinderを知っている場合は
launch binderというアイコンがリポジトリにあると思うのでそこをクリックすればOKです基本的な使い方（開発・公開する側として）
- 自分の作ったリポジトリを他の人に動かしてもらう手段として Binder を活用する方法を書きます．上でも書きましたように特に気張らなくても Binder がいい感じで認識するようなのでなんとなくトライするで済むかもしれません．
- もっと込み入った環境，例えば，PackageCompilerXで重いパッケージのロードを軽くするようにしたJuliaのシステムイメージを使ってもらいたいとなるとなんも考えずにmybinder にアクセスしてよし何してもらうのは難しいでしょう．おそらくそれを実現するにはDockerfileを書くことになります．
- ここではDockerfileによってカスタマイズした環境をBinderに持っていく方法を紹介します．ここでは開発・公開する側はDockerfileの作り方，コンテナ操作などは既知と仮定して話を進めます．手元にDockerfileがあってそれを使うと手元の環境では公開する対象の一通りの動作は確認できるんだけれど，それをどうBinderに認識させるのかがわからない人向けです．
ドキュメントを読む
- 実は Use a Dockerfile for your Binder repository に全てが書いてあります．まずはこちらを読むことをお勧めします．
- Binderの使用上コンテナ内部でrootユーザーになっているようなものは受け付けないようですので
uid is 1000となるユーザーを作ることになります．ドキュメントにもあるようにARG NB_USER=jovyan ARG NB_UID=1000 ENV USER ${NB_USER} ENV NB_UID ${NB_UID} ENV HOME /home/${NB_USER} RUN adduser --disabled-password \ --gecos "Default user" \ --uid ${NB_UID} \ ${NB_USER}を追記しておきます．
jovyanはBinderを動かしている際のユーザー名になるようです．手元で動かすときは-v, --volumeオプションで必要なディレクトリをマウントしてると思いますが，Binderで動かしておくには必要な成果物をCOPYでイメージの中に入れておくことになります．パーミッションの解決のためにchownコマンドでリポジトリの所有者を解決しています．これも Binderのドキュメントに書いてある通りです．# Make sure the contents of our repo are in ${HOME} COPY . ${HOME} USER root RUN chown -R ${NB_UID} ${HOME} USER ${NB_USER}さて，Exampleは？
拙著の MyWorkflow.jl をご覧ください．Dockerfile はこちら．特徴は下記の通り
- PackageCompilerX.jl でパッケージをビルドする
- jupytext で ipynb ではない形式のテキストをJupyterNotebookのフォーマットに自動で変換するようにしている．
- これでバージョン管理をしやすくしている
- 必要なパッケージを導入している
Binder対応のためユーザーをrootと設定してたのでBinderドキュメントの通りにユーザーを追加するにくわえています．
引っかかったところ
- PackageCompierX.jl を使ったビルドの操作がルート権限じゃないとビルドできなくて
- 一方でビルドは通るが一般ユーザー(jovyan) から使おうとすると実行できない．ひとまず所有権を一般ユーザーにすると使えるようになりました．
# Do Ahead of Time Compilation using PackageCompilerX # For some technical reason, we switch default user to root then we switch back again USER root RUN julia --trace-compile="traced.jl" -e 'using OhMyREPL, Revise, Plots, PyCall, DataFrames' && \ julia -e 'using PackageCompilerX; \ PackageCompilerX.create_sysimage([:OhMyREPL, :Revise, :Plots, :GR, :PyCall, :DataFrames]; precompile_statements_file="traced.jl", replace_default=true) \ ' && \ rm traced.jl # Make NB_USER Occupy julia binary RUN chown -R ${NB_UID} /usr/local/julia # Swich user again to NB_USER USER ${NB_USER}多分，一般ユーザーとしてjuliaのバイナリーをインストールすると行けるんだと思いまあすが，ベースイメージが julia:1.3.1 を使ってるので上の方法を採用しています．
- あとは jupytext が.jlをipynbと認識してくれなかったのでc.NotebookApp.contents_manager_class = 'jupytext.TextFileContentsManager'をjupyter_notebook_config.pyに追記することで解決しました．jupytext のリポジトリ には書いてあるのですがルート権限だとなくてもできていたのでハマりました．RUN jupyter notebook --generate-config && \ echo "\ c.ContentsManager.default_jupytext_formats = 'ipynb,jl'\n\ c.NotebookApp.contents_manager_class = 'jupytext.TextFileContentsManager'\n\ c.NotebookApp.open_browser = False\n\ " >> ${HOME}/.jupyter/jupyter_notebook_config.pyBinder用に変換した結果
<- をクリックするとみられます．初回のビルドには結構時間がかかりますね．
Binder の良いところ
- Jupyter Notebook が動くのは多くありますが, Interact.jl， ipywidgets のコンポーネントが動作するのが魅力的です．しかも無料で使うことができます．
- 似たような仕組みとして Google のコラボラトリー がありますが， ipywidgets が動かない制限があるはずです．
- （実は動いてたら教えてください．）
- 回避策としてFormを使うという手段があるようです．Jupyter NotebookとGoogle Colaboratoryを使い比べてみた
例えばこういうことができます．
まとめ
Binderで成果物を共有する方法を書きました．Julia，Python, Rに限らず，Jupyter Notebook で動作する言語であれば同様にできると思うので皆さんトライしてみてください．
- 投稿日：2020-02-06T22:29:01+09:00
docker+Oracle環境下でbuild後に発生したDB接続エラー
事象
docker + oracle/PHPUnit実行環境での開発時、dockerfileの更新を行い
imageをbuildしphpunitを動かすとDB接続エラーが発生。何度かphpunitを実行するとOracleエラーコードが変化する不思議な事象に遭遇した時のお話。
環境情報
開発はdockerコンテナ上に、
・Oracleサーバーを構成し、開発DB環境よりデータをdumpしローカルDB環境へテーブル構造をimportするイメージ
・PHP7環境にphptunitをcomposerでインストールしvolumeしたテストコードを実行するイメージ
のサービス構成となっている。変化していくエラーコード
コンテナを立ち上げ、UnitTestを実行すると以下のエラーが順に発生。
`ORA-12528:TNS:リスナー: 該当するインスタンスはすべて、新規接続をブロックしています` `ORA-12526:TNS:リスナー: 該当するインスタンスはすべて限定モードになっています` `ORA-12537:TNS:接続がクローズされました。` `ORA-01017:ユーザー名/ パスワードが無効です。ログオンは拒否されました。` `ORA-01045: user ユーザ名 lacks CREATE SESSION privilege; logon denied`環境変数
ORACLE_HOMEやORACLE_SIDを再確認し、tnsnames.oraを見直していく中、
変わり身の早さに負けまいと対処を続け、果てにはshutdown & setupも行う。
暫くすると……突然エラー解消、UnitTestが成功。構築環境がカタストロフィではなかったもの、釈然としない。
原因はOracleのstartup
何度か同様の動作を繰り返していくうちに、
・コンテナの再起動では発生しない、再ビルドで発生する
・時間経過で解消される
↓
「dumpしたテーブル構造のimport処理に時間がかかっているのでは？」と推測し、コンテナのプロセスをUnitTest実行時にチェックするようにした。
#!/bin/sh -u # option取得 # * -f オプションで強制的に実行 getopts "f" forceExec # 起動中のコンテナでimportが走っていないか確認 # 自身のgrep処理は除外 if [[ -n `docker-compose exec (database/image) /bin/bash -c 'ps ax | grep -e "(起動script/α)" -e "(起動script/β)" -e "impdp(import処理)" | grep -v "grep"'` ]]; then # option check if [[ ${forceExec} != 'f' ]]; then echo 'now running database script. please wait a few minutes.' exit fi fi # unit test # phpunit は composer.jsonで定義 docker-compose exec (api/image) bash -c 'phpunit (対象directory)'UnitTest実行のshellにチェックを設けて、チーム内周知で一件落着。
インスタンス環境構築の落とし穴に入りかけた一幕と相成りました。
- 投稿日：2020-02-06T22:03:52+09:00
Docker, Docker-compose 良く使うコマンド
docker, Docker-compose 良く使うコマンド
Dockerを使う際に良くコマンドを忘れてしまうので、
自分用の忘備録です。Docker-compose build
docker-compose buildimageを作成・Pullするコマンド、
docker-compose run
docker-compose run (サービス名) （コマンド） example: docker-compose run --rm app bashコンテナを起動して、コマンドを実行することができる。
-rm を追加することによって、コマンドを実行した後に、
コンテナを削除します。docker-compose up する前などに、一時的にコンテナ内に入り
コマンドを実行したい時などに便利です。docker-compose exec
docker-compose exec (サービス名) (コマンド名) example: docker-compose exec app bashこれは、稼働中のコンテナに入りコマンドを実行するための物です。
docker-compose run
docker-compose upこのコマンドを実行すると、
docker-compose.ymlで記述した通りにコンテナを作成し、
コンテナ同士を繋げて起動をします。-d をオプションとしてつけることで、バックグラウンドでコンテナを起動します。
- 投稿日：2020-02-06T19:03:14+09:00
Django3.0の開発環境をDocker,Docker-compose,Poetryで作ってみた
はじめに
Dockerとdocker-composeを使ってDjangoの開発環境を作成します。
他の人が書いた記事にすでにDockerで開発環境をつくる記事はありますが、ライブラリ管理にrequirements.txtを使用しているものも多くあり、現在のパッケージ管理はPipenvやPoetryを使うのが主流となってきている流れもあると思うのでDockerを使った開発でも一目で依存関係がわかるPoetryを使ったほうが良いなと思い記事にしてみました。
また個人的に開発環境にてDockerコマンドでコンテナを起動するのが好きでない（docker-composeのほうが楽）なのでdocker-composeでコンテナを起動する方法を書いてます。
目次
前提
基本的なdockerコマンドとpoetryのコマンドがわかる。
Dockerはインストール済み
docker-composeもインストール済みインストール方法は他の方が書いた記事が沢山あるので割愛します。
動作環境
- MacOS Catalina 10.15.2
- Docker 19.03.5, build 633a0ea
- docker-compose version 1.25.4, build 8d51620a
- docker-image python:3.8
- Python 3.8.1
- Django 3.0.3
Dockerfileの作成
空のDockerfile作成
$ touch DockerfileDocker Hub公式のPythonイメージを使用します。Dockerfileを以下のように記述します。
alpineだとビルド時間がかかるので通常のubuntuベースを使用します。
※以下は例なので適宜編集してくださいFROM python:3.8 WORKDIR /app ENV PYTHONPATH /app ENV LC_ALL=C.UTF-8 LANG=C.UTF-8 RUN apt-get update && apt-get install -y --no-install-recommends \ git \ vim \ && rm -rf /var/lib/apt/lists/* # pipのアップデート RUN pip install --upgrade pip setuptools wheel # Poetryをインストール RUN pip install poetry # コンテナ内で仮想環境の作成を無効 RUN poetry config virtualenvs.create false RUN poetry config virtualenvs.in-project true CMD ["bash"]Poetryのデフォルト設定だとインストール時に仮想環境を作成しようとするので
poetry config virtualenvs.create false
poetry config virtualenvs.in-project true
で無効にしましょう。作成したDockerfileをビルドします。今回は「django」という名前のイメージを作成します。
$ docker build -t django .$ docker run -itd --name django-setting djangoコンテナの中に入り必要なライブラリのインストールと新規Djangoプロジェクトを作成します。
# django-settingコンテナに入る $ docker exec -it django-setting bash # Poetryがインストールされているか確認 <コンテナ>:/app# pip list | grep poetry poetry 1.0.3 # Poetryの初期設定 <コンテナ>:/app# poetry initYesかスキップでOK
consolePackage name [app]: Version [0.1.0]: Description []: Author [None, n to skip]: n License []: Compatible Python versions [^3.8]: Would you like to define your main dependencies interactively? (yes/no) [yes] Search for package to add (or leave blank to continue): Would you like to define your dev dependencies (require-dev) interactively (yes/no) [yes] Search for package to add (or leave blank to continue): Do you confirm generation? (yes/no) [yes]pyproject.tomlが/app 配下に作られていることを確認してdjangoをインストール
<コンテナ内>:/app# ls pyproject.toml <コンテナ内>:/app# poetry add djangoDjangoプロジェクト作成
# プロジェクト名はprojectにしました。 <コンテナ内>:/app# django-admin startproject project . # 作成されていることを確認 <コンテナ内>:/app# ls manage.py poetry.lock project pyproject.tomlctrl + d でコンテナから抜けます。
作成したプロジェクトをコンテナ内からホストのsrcディレクトリへコピーします
# コンテナIDを確認 $ docker ps $ docker cp <コンテナID>:/app/ srcDockerfileを更新します。
先程コンテナからホストにコピーしたpyproject.tomlをコンテナ内にコピーする記述をして
poetry installすることでpyproject.tomlに書いたライブラリが
イメージの作成と同時にpipにインストールされます。FROM python:3.8 WORKDIR /app ENV PYTHONPATH /app ENV LC_ALL=C.UTF-8 LANG=C.UTF-8 RUN apt-get update && apt-get install -y --no-install-recommends \ git \ vim \ && rm -rf /var/lib/apt/lists/* RUN pip install --upgrade pip setuptools wheel RUN pip install poetry RUN poetry config virtualenvs.create false RUN poetry config virtualenvs.in-project true COPY src/pyproject.toml pyproject.toml #追加 RUN poetry install # 追加 CMD ["bash"]Dockerfileを書き換えたので古いコンテナを削除しておく
$ docker ps # コンテナID確認 $ docker rm -f <コンテナID> # django-settingコンテナ削除docker-compose.ymlの作成
空のdocker-compose.yml作成
$ touch docker-compose.ymlDockerfileの準備ができたのでができたのでdocker-compose.ymlの設定をしていきます。
docker-compose.ymlversion: "3" services: django: build: context: . dockerfile: Dockerfile ports: - "8000:8000" volumes: - ./src:/app command: "python3 manage.py runserver 0.0.0.0:8000" tty: true最終的なディレクトリ
. ├── Dockerfile ├── docker-compose.yml └── src ├── manage.py ├── project ├── pyproject.toml └── poetry.lockコンテナの起動
$ docker-compose build $ docker-compose upconsoleStarting django-docker_django_1 ... done Attaching to django-docker_django_1 django_1 | Watching for file changes with StatReloader django_1 | Performing system checks... django_1 | django_1 | System check identified no issues (0 silenced). django_1 | django_1 | You have 17 unapplied migration(s). Your project may not work properly until you apply the migrations for app(s): admin, auth, contenttypes, sessions. django_1 | Run 'python manage.py migrate' to apply them. django_1 | django_1 | February 06, 2020 - 09:38:45 django_1 | Django version 3.0.3, using settings 'project.settings' django_1 | Starting development server at http://0.0.0.0:8000/ django_1 | Quit the server with CONTROL-C.http://localhost:8000
にアクセスすると見えているはず！
cat pyproject.toml[tool.poetry] name = "app" version = "0.1.0" description = "" authors = ["Your Name <you@example.com>"] [tool.poetry.dependencies] python = "^3.8" django = "^3.0.3" [tool.poetry.dev-dependencies] [build-system] requires = ["poetry>=0.12"] build-backend = "poetry.masonry.api"パッケージ管理できてる！
最後に
お疲れさまでした。
- 投稿日：2020-02-06T18:59:13+09:00
Kubernetes上にオブジェクトストレージMinIOをDistributed Modeでインストール
概要 S3互換のあるMinIOをKuberunetesで分散構成にて構築した際の手順です KubernetesのStorageClassにはRookでRBD(Ceph Block Device)を…
- 投稿日：2020-02-06T17:14:07+09:00
elasticsearch snapshot. I Recommend the ’pwd’ command
AccessDeniedException
Unable to access 'path.repo'
- 投稿日：2020-02-06T17:14:07+09:00
elasticsearch snapshot. AccessDeniedException Unable to access 'path.repo'
I Recommend the ’pwd’ command
- 投稿日：2020-02-06T17:11:53+09:00
Web Appの環境変数をコンテナ内のReact Appから呼び出す
失敗談と解決方法です
やらかしたメモ実現させたかったこと
Azure上のApp Serviceで設定した環境変数をデプロイしたDockerイメージで使用したかった。
CRA(Create React App)を使用しているため、.envファイルにREACT_APP_と先頭とつけて書いておくと環境変数として読み込まれる。。
→ App Serviceから環境変数として渡されている値をもとに.envを生成する。試した実装と望んでいた動作
DockerfileのCMDを使用して
Docker runのタイミングで.envを生成するシェルスクリプトを実行する。
↓↓↓CMD [ "/bin/bash", "-c", "./env.sh" ]env.sh#!/bin/bash rm -rf .env touch .env while read -r line || [[ -n "$line" ]]; do if printf '%s\n' "$line" | grep -q -e '='; then varname=$(printf '%s\n' "$line" | sed -e 's/=.*//') varvalue=$(printf '%s\n' "$line" | sed -e 's/^[^=]*=//') fi value=$(printf '%s\n' "${!varname}") [[ -z $value ]] && value=${varvalue} echo "$varname = \"$value\"" >> .env done < .env.key.env.keyREACT_APP_ID = REACT_APP_PW =
.env.keyにある変数名をもとに.envを生成して、下の要領でアプリケーション内で読み込みたかった。id = process.env.REACT_APP_ID; pw = process.env.REACT_APP_PW;原因
.envの読み込みタイミングはDockerfile内のyarn buildが実行されたとき。
yarn buildが実行されているのはdocker buildをした際のみで、.envが生成される前。
docker runが実行されるのもApp Serviceから環境変数が渡されるのもdocker buildが終了し、App Serviceにデプロイされたタイミング。
→.envの生成自体は成功していたが読み込まれていなかった。ただのミスだった…
解決策
下記のようにenvファイルを変更して、環境変数を保持するjsファイルを生成する。
index.htmlのheadでスクリプトとして読み込ませることで、window._env_.***として呼び出すことができる。呼び出しid = window._env_.REACT_APP_ID; pw = window._env_.REACT_APP_PW;env.sh#!/bin/bash rm -rf ./env-config.js touch ./env-config.js echo "window._env_ = {" >> ./env-config.js while read -r line || [[ -n "$line" ]]; do if printf '%s\n' "$line" | grep -q -e '='; then varname=$(printf '%s\n' "$line" | sed -e 's/=.*//') varvalue=$(printf '%s\n' "$line" | sed -e 's/^[^=]*=//') fi value=$(printf '%s\n' "${!varname}") [[ -z $value ]] && value=${varvalue} echo " $varname: \"$value\"," >> ./env-config.js done < .env echo "}" >> ./env-config.jsindex.html<head> ... <script src="%PUBLIC_URL%/env-config.js"></script> ... </head>参考
- 投稿日：2020-02-06T16:44:44+09:00
【Docker】 Redis で Error: Redis connection to 127.0.0.1:6379 failed - connect ECONNREFUSED 127.0.0.1:6379 と出てきたときの対処法
エラー内容
Dockerで構築したRedisにNode.jsからアクセスしようとしたら以下のようなエラーがでた
Error: Redis connection to 127.0.0.1:6379 failed - connect ECONNREFUSED 127.0.0.1:6379原因
Redisに接続するときのデフォルトはローカルホストを参照するように出来ているのでコンテナに接続することが出来ない
対処法
Node.jsからアクセスする際に直接ホストを指定してあげる
app.jsconst redis = require('redis') const client = redis.createClient(6379, 'redis')
- 投稿日：2020-02-06T16:27:32+09:00
Docker ただの基礎からの復習
1.Dockerのインストール
1-1Docker Desktop for 〇〇をダウンロードし、インストールする
Docker Desktop for Mac
Docker for Mac で Dockerコンテナを実行する場合、MacOSで直にコンテナが動作するのではなく、HyperKitというMacの仮想化機能を利用して内部的には軽量のLinuxを動作させ、その上でDockerコンテナを実行します。本編は、Docker Desktop for Mac を利用していますが、基本的なDockerコマンドなどの使い方はWindowsも同じです。
Windowsをお使いの場合は、Windows Docker Desktop for Windowsを利用してください。2.Dockerコンテナの実行
2-1 hello-worldを動作させてみよう
とりあえず、hello-worldイメージを実行し、コンテナを動かして見ましょう。
docker run hello-world
初回は、インターネット経由でDocker HubからDockerイメージをダウンロードしてきます。
同じDockerイメージがPC上に存在する場合は、②③が省略され、ローカル上にあるDockerイメージからDockerコンテナが実行されます。
:でタグを指定できます。指定が何もない場合は、latest（最新）となります。下記のように実行してみましょう。ただし、実行結果は「2-1.hello-worldを動作させてみよう」と同じ結果になります。
docker run hello-world:latest2-2 Dockerイメージ
Dockerイメージとは、コンテナの実行に必要なファイルを纏めたファイルシステムです。
一度作成したイメージのレイヤーは、「読み取り専用」となり変更を加えることはできません。
コンテナレイヤー上にファイルの追加や削除を行い、それをまたDockerイメージとして保存することも可能です。whalesayイメージを実行し、Helloと喋らせてみましょう。
docker run docker/whalesay cowsay Hello Unable to find image 'docker/whalesay:latest' locally latest: Pulling from docker/whalesay e190868d63f8: Pull complete 909cd34c6fd7: Pull complete 0b9bfabab7c1: Pull complete a3ed95caeb02: Pull complete 00bf65475aba: Pull complete c57b6bcc83e3: Pull complete 8978f6879e2f: Pull complete 8eed3712d2cf: Pull complete Digest: sha256:178598e51a26abbc958b8a2e48825c90bc22e641de3d31e18aaf55f3258ba93b Status: Downloaded newer image for docker/whalesay:latest _______ < Hello > ------- \ \ \ ## . ## ## ## == ## ## ## ## === /""""""""""""""""___/ === ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ / ===- ~~~ \______ o __/ \ \ __/ \____\______/ローカル上にダウンロード済みのDockerイメージの一覧を表示させてみましょう。
docker imagesDockerイメージにタグ付けすることも可能です。
docker tag docker/whalesay whalesay:v1コンテナの情報を取得してみましょう。
docker inspect docker/whalesay作成したdocker/whalesayを削除してみましょう。
なお、dockerが起動しているときにDockerイメージを削除することはできません。
dockerが起動しているときに、強制的にDockerイメージを削除する場合は、docker rmi の後に-fをつけることによって、強制的に削除することも可能ではあります。（下記の例では、-f は使っていません。）docker rmi docker/whalesayDockerイメージを削除したので、Dockerコンテナは実行せず、Dockerイメージをダウンロードだけするには、pullします。
docker pull docker/whalesay2-3 Dockerファイル
先程は、DockerイメージをDocker Hubから取得してきましたが、Dockerファイルを作成してビルドすることも可能です。
まず、作業用のフォルダを作成しておきましょう。
mkdir imagebuild cd imagebuild下記のとおり、Dockerfileを作成します。
DockerfileFROM docker/whalesay:latest RUN apt-get -y update && apt-get install -y fortunes CMD /usr/games/fortune | cowsay ## FROM : ベースイメージの指定 ## RUN : コマンド実行 ## CMD : デーモン実行作成したDockerfileファイルからイメージをビルドするには以下のコマンドを実行します。
-tはタグの指定です。docker build -t docker-whale .ビルドしたイメージを実行して見ましょう。
docker run docker-whale ________________________________________ / As the trials of life continue to take \ | their toll, remember that there is | | always a future in Computer | | Maintenance. | | | \ -- National Lampoon, "Deteriorata" / ---------------------------------------- \ \ \ ## . ## ## ## == ## ## ## ## === /""""""""""""""""___/ === ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ / ===- ~~~ \______ o __/ \ \ __/ \____\______/ちなみに２回目以降、キャッシュをを使用せずビルドするには、以下のように実行します。
docker build --no-cache -t docker-whale .次に自身で作成したDockerイメージをDockerHubに公開して見ましょう。
[DockerHub]の Repository に docker-whale を作成しておいてください。Docker Hubにログインします。
docker loginタグをつけておきます。
docker tag docker-whale <Docker ID>/docker-whale:v1DockerイメージをDockerHubにPushし、DockerHubにあることを確認しましょう。
docker push <Docker ID>/docker-whale:v12-4 デタッチモード(-d)
-dはデタッチモードといい、コンテナの実行をバックグラウンドで行うものです。docker run --name nginx-d1 -d -p 8080:80 nginx
http://localhost:8080/にアクセスすると表示されると思います。なお、
-pの動作について図で簡単に見ておきましょう。
localhost:8080はコンテナのPort:80に転送するという意味です。
-dをつけない場合との動作の違いを確認しておきましょう。docker run --name nginx-d2 -p 8080:80 nginx
http://localhost:8080/にアクセスして見ましょう。WEBページの表示は変わりませんが、WEBページにアクセスした際、↓のようにログが画面に流れていることがわかります。
172.17.0.1 - - [03/Jul/2019:10:38:14 +0000] "GET / HTTP/1.1" 304 0 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36" "-" 172.17.0.1 - - [03/Jul/2019:10:38:22 +0000] "GET / HTTP/1.1" 304 0 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36" "-"この状態ではフォアグラウンドで動作しているので、
ctrl+Cでプロセス終了した場合、コンテナも停止されてしまうという違いがあります。
そのため、WEBページなどは基本デタッチモードで動作させるようします。2-5 マウント(-V)
ホストマシンにあるディレクトリをコンテナ上にマウントしてみましょう。
私はMacを利用しています。まずは、
/Users/<ユーザ名>/docker/htmlにindex.htmlを作成しておきます。index.html<!DOCTYPE html> <html> <body> <h1>hellow</h1> </body> </html>では、マウントしてみましょう。
docker run --name nginx-m1 -v /Users/<ユーザ名>/docker/html:/usr/share/nginx/html:ro -d -p 8080:80 nginx
http://localhost:8080/にアクセスし表示されるか確認しましょう。
表示されたことが確認できたら、/Users/<ユーザ名>/docker/html/index.htmlの内容を編集し、編集内容が反映されているかも再度アクセスして確認してみましょう。2-6 コピー（copy）
COPYコマンドはホストマシン↔︎コンテナ内にコピーするコマンドです。
Dockerコンテナを用意しておきます。
docker run --name nginx-c1 --rm -d nginx作業しやすいように、copyディレクトリを作成しておきます。
mkdir copy cd copy/copyコマンドで設定ファイルを取り出してみます。先程作成したnginx-c1の中にあるdefault.confを取り出します。lsでコピーされたかも確認しておいてください。
docker cp nginx-c1:/etc/nginx/conf.d/default.conf ./ lsここでは、動作検証のためにわざとlisten:8080に変え、→ DockerFileを作成し、→ ビルドします。
default.conflisten:8080 ## 80→8080に変更する。DockerfileFROM nginx:latest COPY default.conf /etc/nginx/conf.d/default.confdocker build -t nginx:c2 .Dockerコンテナをlisten:80で実行しますが、これは先程default.confをlisten:8080に変更したのでアクセスできません。
docker run --name web -p 8080:80 --rm nginx:c28080番ポートだと、アクセスできるようになりました。
docker run --name web -p 8080:8080 --rm nginx:c22-7 Dockerの基本コマンド
iはコンテナの標準入力を取得して、双方向に接続できるようにするもので、
tはコンテナ内にttyを割り当てる意味があります。
コンテナでシェルを実行して、フォアグラウンドで実行状態にしておきたい場合はよく使われます。docker create --name c-container -it alpine /bin/shコンテナの一覧を表示させるコマンドです。
docker ps 実行中のコンテナを表示する。 docker ps -a 実行中以外のコンテナも表示する。その他、Dockerを開始や停止するコマンドです。
docker start 開始 docker stop 停止 docker pause 一時停止 docker unpause 一時停止を解除2-8 シェルへの接続(attach,exec)
起動中のコンテナに接続する方法を確認して行きましょう。2通りあります。
attach
exec☆推奨とりあえず、Dockerコンテナを起動します。
docker run --name shell-1 -it ubuntu /bin/bashまずは、
attachで接続して、exitで抜けてみます。
attachで接続し、exitで抜けた場合は、プロセスが終了し、コンテナも終了されてしまうので注意が必要です。
基本的にはctrl+p ctrl+qでぬけることで、コンテナも終了せずにできます。
ただし、起動時に-itをつけていない場合は、ctrl+p ctrl+qでぬけることができません。docker attach shell-1 exit次に、
execで接続し、同じようにexitで抜けてみましょう。
この場合は、exitで抜けてもコンテナは起動したままの状態です。
そのため、基本的にはexecで接続するようにします。docker exec -it shell-1 /bin/bash exit2-9 docker commit
commitコマンドは、コンテナに対して行った設定や更新したファイルを、新しいDockerイメージとして格納することが出来ます。
ただし、コンテナ内で行われた作業はどこにも明確な記録として残らないため、極力「2-3 Dockerファイル」を使うようにしましょう。Dockerコンテナを作成しておきます。
docker run --name commit-1 -it -d --rm ubuntu /bin/bashこのDockerコンテナに、何かしらの変更をしておきます。
docker exec -it commit-1 /bin/bash cd /tmp/ dd if=/dev/zero of=tempfile bs=1M count=10 exitcommit-1をcommit-2としてコミットし、→ 新しいDockerコンテナを起動すると完了です。
docker commit commit-1 commit-2 docker run -it commit-2 /bin/bash2-10 リンク(--link)
コンテナ名、またはエイリアスでリンク先に通信できるようにします。
ただし、--linkオプションはすでに非推奨ですので、後述の「Dockerのネットワーク」を主に学習してください。
なので、ここでは--linkオプションについては簡単な操作だけ行います。
作業用のproxyというフォルダを作成しておきましょう。
mkdir proxy cd proxyreverse_proxy.conf を作成しておきます。
reverse_proxy.confserver { listen 8080 server_name localhost; location / { proxy_pass http://ss; } }先程作成したreverse_proxy.confを使い、Dockerfileを作成します。
DockerfileFROM nginx:latest COPY /reverse_proxy.conf /etc/nginx/conf.d/reverse_proxy.conf RUN apt-get update && apt-get install -y inetutils-pingproxyという名前でDockerfileをビルドします。
docker build -t proxy .dockersamples/static-siteのdockerコンテナを実行します。
docker run --name website -e AUTHOR="naata" -d dockersamples/static-siteproxyのdockerコンテナを実行します。
docker run --name webproxy -p 8080:8080 --link website:ss -d proxywebsiteとwebproxyのdockerコンテナが起動していることを確認しておきます。
docker ps
http://localhost:8080にアクセスして表示されるか確認してみましょう。これで、webproxyを経由して、websiteが表示されていることになります。3 Automated build
Githubなどのソースコードのホスティングサービスでビルドテキストを管理し、リポジトリ上のビルドコンテキストを管理し、リポジトリ上のビルドコンテキストの内容が変更された場合に自動的にビルドを実行する仕組み。
3-1 GitHub にレポジトリを作成
Githubに
Docker_Automated_buildというrepositoryを作成しておいてください。3-2 Dockerhub 設定
自分のアカウントから[Account Settings]をクリック。
[Linked Accounts]のGitHubで[Connect provider]をクリック。
docker_repositoryを
docker_automated_buildで作成し、「3-1 GitHub にレポジトリを作成」で作成したgit_repositoryを選択する。
基本的な設定は以上なので、検証していきます。
3-3 検証##
以下は通常のgit操作となりますので、詳しい説明は省略します。
git config --global user.name "" git config --global user.email "" git clone https://github.com/aaa/Docker_Automated_build cd Docker_Automated_build/DockerfileFROM dockersamples/static-site ENV AUTHOR="naata"git add Dockerfile git commit -m "First Automated" git push origin masterDockerHubを確認し、SUCCESSとなっていればOK
念のため pull して確認もしておきましょう。
docker pull aaa/docker_automated_build docker images4 Docker Machine
4-1 Docker Machine
Docker Machineは、Docker for Mac / Docker for WindowsまたはDocker toolboxに付属してインストールされるソフトウェアです。
Docker Engineをインストールした仮想マシンの作成、起動、停止、再起動などをコマンドラインから実行することができるツールです。4-2 Dockerホストの作成
単純にローカルPCにDockerホストを作成していきます。
docker-machine create --driver virtualbox default作成されたか確認して見ましょう。
docker-machine ls作成されたDockerホストに接続して見ましょう。操作対象のDockerホストを設定するための、設定コマンドが表示されます。
環境変数を設定すると、Docerコマンドの操作対象がenvの引数に指定したDockerホストに設定されます。docker-machine env default eval $(docker-machine env default)確認のために、hello-worldコンテナを実行し見ましょう。
docker run hello-worldDockerホストにsshすることもできます。
docker-machine ssh defaultexitで抜けましょう。
exitdockerホストのipを確認し、nginxを実行し、このipでwebページがかえってくるか確認して見ましょう。
docker-machine ip default docker run -d -p 8080:80 nginxdocker-machine を明示的に停止、開始するには以下の通り指定します。
docker-machine stop default docker-machine start defaultactiveなdocker-machineを解除するには。
docker-machine env -u eval $(docker-machine env -u)5 Dockerのネットワーク
「2-10 リンク(--link)」で紹介した
--linkオプションは利用せず、ユーザー定義ネットワークを使う方法が推奨されています。docker networkの一覧を表示すると、デフォルトで3つのネットワークがあることがわかります。
docker network ls NETWORK ID NAME DRIVER SCOPE 3d43dcdb4080 bridge bridge local 8b1af105abd9 host host local afffac7bcd1b none null local5-1 bridge
コンテナはデフォルトでブリッジドライバーに所属します。
ブリッジネットワークの詳細を確認して見ましょう。
docker network inspect bridge subnet → このネットワーク内のipが割り当てられる。 Getway → dockerホストのdocker0に割り当てられたI/Fとなります。コンテナを2つ起動して見ましょう。
docker run -itd --name net1 alpine /bin/sh docker run -itd --name net2 alpine /bin/shそれぞれのコンテナにipが割り当てられたことを確認します。
docker inspect brigeコンテナ net1 ↔︎ net2 で疎通ができるか確認してみましょう。
ping <ip>なお、デフォルトでdnsは提供されないため、コンテナ名で通信することはできません。そのため、ネットワークを追加します。
docker network create my_netこれに先ほどのコンテナ2台を追加します。
docker network connect my_net net1 docker network connect my_net net2これで、 net1 ↔︎ net2 がコンテナ名で通信できるか確認してみましょう。
ping <コンテナ名>ちなみに、最初からmy_netネットワークに所属させるためには以下のコマンドを使います。
docker run -itd --name net3 --network my_net alpineまた、ネットワークを切り離すには以下のとおり実行します。
docker network disconnect bridge net25-2 none
nullドライバに接続してコンテナは、ループバックI/F以外にネットワークI/Fを持たない状態になります。
また、noneネットワークを接続するコンテナは、その他の全てのネットワークを切断した状態にしなければいけません。docker run -itd --name none1 --network none alpine /bin/shdocker attach none1 ip addr show / # ip addr show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever5-3 host
hostドライバを使用したネットワークです。
hostネットワークに接続したコンテナはdockerホストと同じネットワーク設定を持ちます。
ホストネットワークのコンテナでwebサーバーを起動した場合、ホストマシンのipの80でlistenしているのと同じ動作になります。
そのため、-p を利用しなくても、コンテナを起動しただけで、dockerホストの80にアクセスすれば、コンテナの80に接続することができます。docker run -d --name host --network host nginxhostのipにアクセスして表示されるか確認だけしておきましょう。
6 Dockerのデータ管理
コンテナで扱う動的なデータは起動中のコンテナの読み書き可能なレイヤーにおくこともできますが、いくつかのデメリットがあります。
それは、
・コンテナが削除された時点でデータは消えてしまう。
・コンテナ間でデータを共有することができない。
・書き込みのパフォーマンスもホスト上へのデータの書き込みに加えて、書き込みのパフォーマンスがよくない。
これは、通常のファイルシステムとは異なるユニオンファイルシステムが利用されているためです。
dockerにはホスト上のディレクトリやファイルをコンテナにマウントする仕組みやホストのメモリをファイルシステムとしてコンテナにマウントする仕組みが用意されています。6-1 volume
複数のコンテナにマウントすることもでき、複数のコンテナで共通のファイルを読み書きすることができます。
ただし、異なるホスト間で共有することはできません。
ボリュームはコンテナが削除されても消えず、明示的に削除するまで消えません。まずは、docker volumeコマンドをいくつか覚えましょう。
docker volumeを作成するコマンドです。
docker volume create vol-1一覧を表示するコマンドです。
docker volume ls詳細情報を確認するコマンドです。
docker volume inspect vol-1削除するコマンドです。
docker volume rm vol-1ではここから、volumeをマウントする方法です。2つの方法があります。
-v
--mount→ 基本的にこっちの方が推奨されているのでこっちで覚えましょう。今回は-vでも試してみます。ここではまだvolumeがないのでvol2を作成ています。
docker run -itd --name mount1 -v vol2:/app nginx--mountで試します。
docker run -itd --name mount2 --mount source=vol2,target=/app nginxdocker execで接続して、同じファイルがあるか確認しておきましょう。
docker exec -itd mount1 /bin/bash cd /app touch hogehoge exit docker exec mount2 cd /app読み取り専用（readonly）にする場合は、以下のとおり実行します。
docker run -itd --name mount3 --mount source=vol3,destination=/etc/nginx,readonly nginx6-2 bind mount
ホストが管理しているファイルやディレクトリをコンテナにマウントします。これも2つの方法があります。
-v
--mount→ 基本的にこっちが推奨されているのでこっちを使います。-vでカレントディレクトリに存在しないディレクトをマウントします。
docker run -itd --name bindmount1 -v "$(pwd)"/source:/app nginxlsでsourceディレクトリが作成されていることを確認しておきましょう。
ls T632717CF0F94D06EE source--mountを利用する場合は、
type=bindを指定します。docker run -itd --name bindmount2 --mount type=bind,source"$(pwd)"/source2,target=/app nginxエラーになったと思います。
--mountではディレクトが存在しない場合はエラーになります。これにより謝って空のディレクトリをマウントしてしまわないことを防ぎます。6-3 tmpfs
ホストのメモリ領域をマウントします。ホストやDockerがシャットダウンされた場合は、データは消えます。なので、一時的なものをおくために利用します。
type=tmpfsで指定します。docker run -itd --name tmpfs1 --mount type=tmpfs,destination=/app nginx7 Docker Compose
Docker compose とは、複数のコンテナから成るサービスを構築・実行する手順を自動的にし、管理を容易にする機能です。
Docker compose では、compose ファイルを用意してコマンドを1 回実行することで、そのファイルから設定を読み込んですべてのコンテナサービスを起動することができます。7-1 docker-compose.yml
サービス 説明 image ベースイメージの指定 build Dockerfileの指定 command コンテナ内で実行するコマンドの設定 links コンテナ間リンク設定 ports ホストOS外部への公開ポート設定 expose コンテナ間のみでの公開ポート設定 volumes ボリュームマウントの設定 volumes_from 別コンテナをボリュームとしてマウントするための設定 environment 環境変数設定 env_file 環境変数をファイル読み込みで設定 container_name コンテナの名前設定 7-2 docker-composeインストール
OSごとのインストール方法は↓。
Install Docker Composeインストールされていることを確認しておきましょう。
docker-compose --version7-3 docker-compose.ymlの作成
作業ディレクトリ
docker-compose-testを作成しておきましょう。mkdir docker-compose-test cd docker-compose-testここでは、
dbとwordpressを作成しています。docker-compose.ymlversion: '3' services: db: image: mysql:5.7 volumes: - "./.data/db:/var/lib/mysql" restart: always environment: MYSQL_ROOT_PASSWORD: wordpress MYSQL_DATABASE: wordpress MYSQL_USER: wordpress MYSQL_PASSWORD: wordpress wordpress: depends_on: - db image: wordpress:latest links: - db ports: - "8000:80" restart: always environment: WORDPRESS_DB_HOST: db:3306 WORDPRESS_DB_PASSWORD: wordpress後は以下コマンドで起動完了です。
docker-compose up -d8 dockerignore
Dockerfileからイメージをビルドする場合、Dockerfileの存在するディレクトリの中身はtarで固められdaemonへと送られます。
このようなimageに含まないファイルも送信するため、dockerignoreを使います。そもそも不要なファイルを含めなければいいと思いますが。。。
詳しくは、↓のページを参考にさせていただきました。
.dockerignore アンチパターン
- 投稿日：2020-02-06T14:56:33+09:00
【 Docker 】 あとから --restart always を適用する
- 投稿日：2020-02-06T13:07:10+09:00
Docker + Create React Appで環境変数を使いたかった（自戒）
失敗談と解決方法です
やらかしたメモ実現させたかったこと
Azure上のApp Serviceで設定した環境変数をデプロイしたDockerイメージで使用したかった。
CRA(Create React App)を使用しているため、.envファイルにREACT_APP_と先頭とつけて書いておくと環境変数として読み込まれる。。
→ App Serviceから環境変数として渡されている値をもとに.envを生成する。試した実装と望んでいた動作
DockerfileのCMDを使用して
Docker runのタイミングで.envを生成するシェルスクリプトを実行する。
↓↓↓CMD [ "/bin/bash", "-c", "./env.sh" ]env.sh#!/bin/bash rm -rf .env touch .env while read -r line || [[ -n "$line" ]]; do if printf '%s\n' "$line" | grep -q -e '='; then varname=$(printf '%s\n' "$line" | sed -e 's/=.*//') varvalue=$(printf '%s\n' "$line" | sed -e 's/^[^=]*=//') fi value=$(printf '%s\n' "${!varname}") [[ -z $value ]] && value=${varvalue} echo "$varname = \"$value\"" >> .env done < .env.key.env.keyREACT_APP_ID = REACT_APP_PW =
.env.keyにある変数名をもとに.envを生成して、下の要領でアプリケーション内で読み込みたかった。id = process.env.REACT_APP_ID; pw = process.env.REACT_APP_PW;原因
.envの読み込みタイミングはDockerfile内のyarn buildが実行されたとき。
yarn buildが実行されているのはdocker buildをした際のみで、.envが生成される前。
docker runが実行されるのもApp Serviceから環境変数が渡されるのもdocker buildが終了し、App Serviceにデプロイされたタイミング。
→.envの生成自体は成功していたが読み込まれていなかった。ただのミスだった…
解決策
下記のようにenvファイルを変更して、環境変数を保持するjsファイルを生成する。
index.htmlのheadでスクリプトとして読み込ませることで、window._env_.***として呼び出すことができる。呼び出しid = window._env_.REACT_APP_ID; pw = window._env_.REACT_APP_PW;env.sh#!/bin/bash rm -rf ./env-config.js touch ./env-config.js echo "window._env_ = {" >> ./env-config.js while read -r line || [[ -n "$line" ]]; do if printf '%s\n' "$line" | grep -q -e '='; then varname=$(printf '%s\n' "$line" | sed -e 's/=.*//') varvalue=$(printf '%s\n' "$line" | sed -e 's/^[^=]*=//') fi value=$(printf '%s\n' "${!varname}") [[ -z $value ]] && value=${varvalue} echo " $varname: \"$value\"," >> ./env-config.js done < .env echo "}" >> ./env-config.jsindex.html<head> ... <script src="%PUBLIC_URL%/env-config.js"></script> ... </head>参考
- 投稿日：2020-02-06T11:44:26+09:00
Laravel/uiを入れたらnpmが通らない[apt-get等でnpmとnodeが古いケース+Docker環境]
ハマったので備忘録。
問題
Laravel/uiを入れた後には
npm installして必要なモジュールをインストールする。自分の場合は開発環境でdocker越しにlaravelの環境を動かしていて、
npmはapt-get install -y node npmでインストールしていた。その後、
$ composer require laravel/ui $ php artisan ui vue --authでlaravel/uiをインストールした後、
$ npm installが途中で止まって進まない。
という問題に直面した。
IEEEなんたらうろ覚えというモジュールの近辺で静止する。解決
ログを見ると実行した直後に警告が出ており、現在のnpmとnodeは対応してないという警告が出ていた。
どうもapt-getで得られていたnpmとnodeのバージョンが古いようで、
apt-getではなく、npmとnodeを公式のホームページから直接インストールすることで解決した。
(下のDockerfileの今回の解決手順の所を参考)dockerのコンテナで動かしていたため、自分はアンインストールは不要だったが、
自動的にnpmとnodeのインストールが破棄されない場合は、
アンインストールの手順が必要になるかもしれない。Dockerfile[参考]FROM php:7.4.2-apache RUN apt-get update #composer install RUN php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');" \ && php -r "if (hash_file('sha384', 'composer-setup.php') === 'c5b9b6d368201a9db6f74e2611495f369991b72d9c8cbd3ffbc63edff210eb73d46ffbfce88669ad33695ef77dc76976') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;" \ && php composer-setup.php \ && php -r "unlink('composer-setup.php');" RUN mv composer.phar /usr/local/bin/composer RUN composer self-update #node,npm install--今回の解決手順 #nodeのversionは必要に応じて変更すること。 #Dockerでない場合はnode npmのアンインストールがおそらく必要（手順未確認）。 #アンインストールが成功した場合は、RUN以下をlinuxコマンドに読み替えて実行する。 RUN apt-get install -y wget RUN wget https://nodejs.org/dist/v12.14.1/node-v12.14.1-linux-x64.tar.xz RUN tar -xf node-v12.14.1-linux-x64.tar.xz RUN mv node-v12.14.1-linux-x64/bin/* /usr/local/bin/ RUN mv node-v12.14.1-linux-x64/lib/node_modules/ /usr/local/lib/ #php plugin install RUN docker-php-ext-install pdo_mysql mysqli #for Laravel rooting #このコンテナのイメージ元のphp:7.4.2-apacheではrewirte.soが標準で読み込まれていない。 #Laravelのrootingには必要なモジュールなので読み込ませる。 RUN mv /etc/apache2/mods-available/rewrite.load /etc/apache2/mods-enabled/ #debug soft install RUN apt-get -y install vim追記：
Dockerは本当はnpm、http、phpは別コンテナにした方が
良いのかもしれないけれども、参考までに。追記2:
rootingが動かなかったので動くように参考のDockerfileを修正
- 投稿日：2020-02-06T10:51:21+09:00
Docker環境にてPHPのデバッグができるかどうか、やってみた
はじめに
・今の職場にてPHPの開発をしているだが、デバッグができなくて困っている。苦肉の策でログを出しながら確認しているが、なんとかしたいと思い。
最近かじったDocker環境にてPHPのデバッグができる様なので、試しにやってみた。環境
・使用パソコンスペック
PC: Razer Brade pro 2019
OS: Ubuntu 18.04 LTS
Docker: version 19.03.5
Docker Compose: version 1.17.1
PHP: php:7.2.7-apache (Apacheと連携されているコンテナ)
Xdebug: 2.7.0
Visual Studio Code: 1.41.1DockerfileFROM php:7.2.7-apache RUN apt-get update && \ docker-php-ext-install mysqli && \ pecl install xdebugdocker-compose.ymlversion: '3' services: php: build: ./php ports: - '80:80' volumes: - ./php/html:/var/www/html - ./php/conf/php.ini:/usr/local/etc/php/php.ini - ./php/log/xdebug:/var/log/xdebugphp.ini[Date] date.timezone = "Asia/Tokyo" [mbstring] mbstring.internal_encoding = "UTF-8" mbstring.language = "Japanese" [xdebug] ; xdebugのインストール先を指定(Dockerコンテナ内) zend_extension=/usr/local/lib/php/extensions/no-debug-non-zts-20170718/xdebug.so xdebug.remote_enable=1 xdebug.remote_autostart=1 ; デバッグで使用するポートを指定(デフォルト値) xdebug.remote_port=9222 ; Dockerコンテナ内部から見たホストを指定 xdebug.remote_host=host.docker.internal ; ログ出力先 xdebug.remote_log=/var/log/xdebug/xdebug.log xdebug.remote_connect_back=1launch.json{ "version": "0.1.0", "configurations": [ { "name": "Listen for XDebug", "type": "php", "request": "launch", "port": 9222, "pathMappings": { // Dockerコンテナのdocument root : 開発環境のdocument root "/var/www/html":"${workspaceFolder}/php/html" } } ] }index.php<?php echo 'Hello World<br>';はまった点
・Dockerの立ち上げから、HTTPへのアクセスまではすんなりいったが、ブレイクポイントで止まらなかった。結果、launch.jsonのポートの設定を自分の環境で使用しているものに変更したら動きました。
・xdebugのインストール先を指定(Dockerコンテナ内)をphp.iniファイルに記入するのが抜けていたため動かなかった。※環境によってパスが変わるようであり、Dockerを立ち上げたときにコマンド上でインストールされたパスが確認できる。参考にさせていただいたリンク
・Docker-composeのコマンド
https://qiita.com/okyk/items/a374ddb3f853d1688820
・構築方法
https://qiita.com/MasanoriIwakura/items/a310c75e6c5b347adf37
- 投稿日：2020-02-06T10:51:21+09:00
Docker環境にて、PHPのデバッグができるかどうか試しにやってみた
はじめに
・今の職場にてPHPの開発をしているだが、デバッグができなくて困っている。苦肉の策でログを出しながら確認しているが、なんとかしたいと思い。
最近かじったDocker環境にてPHPのデバッグができる様なので、試しにやってみた。使用ツール
項目 バージョン PC Razer Brade Pro 2019 OS Ubuntu 18.04 LTS Docker 19.03.5 Docker-Compose 1.17.1 PHP php:7.2.7-apache (連携されているコンテナ) Xdebug 2.7.0 Visual Studio Code 1.41.1 DockerfileFROM php:7.2.7-apache RUN apt-get update && \ docker-php-ext-install mysqli && \ pecl install xdebugdocker-compose.ymlversion: '3' services: php: build: ./php ports: - '80:80' volumes: - ./php/html:/var/www/html - ./php/conf/php.ini:/usr/local/etc/php/php.ini - ./php/log/xdebug:/var/log/xdebugphp.ini[Date] date.timezone = "Asia/Tokyo" [mbstring] mbstring.internal_encoding = "UTF-8" mbstring.language = "Japanese" [xdebug] ; xdebugのインストール先を指定(Dockerコンテナ内) zend_extension=/usr/local/lib/php/extensions/no-debug-non-zts-20170718/xdebug.so xdebug.remote_enable=1 xdebug.remote_autostart=1 ; デバッグで使用するポートを指定(デフォルト値) xdebug.remote_port=9222 ; Dockerコンテナ内部から見たホストを指定 xdebug.remote_host=host.docker.internal ; ログ出力先 xdebug.remote_log=/var/log/xdebug/xdebug.log xdebug.remote_connect_back=1launch.json{ "version": "0.1.0", "configurations": [ { "name": "Listen for XDebug", "type": "php", "request": "launch", "port": 9222, "pathMappings": { // Dockerコンテナのdocument root : 開発環境のdocument root "/var/www/html":"${workspaceFolder}/php/html" } } ] }index.php<?php echo 'Hello World<br>';はまった点
・Dockerの立ち上げから、HTTPへのアクセスまではすんなりいったが、ブレイクポイントで止まらなかった。結果、launch.jsonのポートの設定を自分の環境で使用しているものに変更したら動きました。
・xdebugのインストール先を指定(Dockerコンテナ内)をphp.iniファイルに記入するのが抜けていたため動かなかった。※環境によってパスが変わるようであり、Dockerを立ち上げたときにコマンド上でインストールされたパスが確認できる。参考にさせて頂いた記事
・Docker-composeのコマンド
https://qiita.com/okyk/items/a374ddb3f853d1688820
・構築方法
https://qiita.com/MasanoriIwakura/items/a310c75e6c5b347adf37
- 投稿日：2020-02-06T08:51:09+09:00
ヘッドレスインストール—Docker on Alpine Linux on Raspberry Pi Zero W
ドッカー・オン・アルパイン・リナックス・オン・ラズベリー・パイ・ゼロ・ダブリュー
意地でもモニタを繋げたくなかった。
インストール
Alpineは何もしないとディスクレスで動くが、RPi0にはメモリが512MBしかない。普通にインストールしてDockerデーモンをブート時に起動させようとすると、必要なパッケージ類が全てメモリ上に置かれることになり容量不足で落ちるっぽいかもなのです1。なのでディスクに書き込む普通のインストールを行う。
事前準備
まずはmicroSDカードを準備する。基本的にはここを読んで従うだけ。
なのだが、ヘッドレスインストールするためにはブート前にWi-FiやSSHのセットアップをしなければならない。追加で以下の作業が必要。
これはブート時に呼び出される
/bin/hostnameをフックしてそれらの設定を済ませてしまおうというもの。つまり要約すると、ブート前の作業は、
- microSDカードをフォーマットする
- Alpine Linuxのarmhf用パッケージを解凍してぶちこむ
- オーバーレイを作成してぶちこむ
という流れになる。
ブート
これも基本的にはここを読んで従うだけ。
ただし最後の
rebootの前にやっておく必要のある作業がある。先ほどWi-FiとSSHをオーバーレイで設定したが、今/mntにマウントしたAlpine Linuxにはそれらは反映されておらず、setup-alpineによる初期設定のみが反映されているっぽいかもなのです。つまりここでrebootしてしまうと、Wi-Fiの設定はsetup-alpine中に行なったので問題ないが、SSHの設定はデフォルトのままなのでrootでパスワードレスログインできなくなってしまう。したがってこの時点で
/mnt/etc/ssh/sshd_configを編集したり/mnt/root/.ssh/authorized_keysを作成したりしなければならない。必要なところを編集したら
reboot。峠は越えた。Dockerセットアップ
Dockerのインストールは下記参照。
以下略。以上。
回避する方法があったら知らせなさい ↩
- 投稿日：2020-02-06T08:20:16+09:00
wsl2に入門してみた(導入からdocker-compose upまで)
5月が待ちきれずWSL2を導入してしまいました。
もともと、windowsPCにubuntuをデュアルブートして使っていました。
しかし、デュアルブートしているとwindows側に不具合が生じたり、起動の手間が増えることから若干不便を感じていた矢先、ubuntuちゃんがまさかのクラッシュ！
設定も全部飛んでしまったので、wslに入門してみようと思いました。
WSL2とは
WSLとはＷindows Ｓubsystem for Ｌinuxの略で、windowsの内部でlinuxが動くというまさに夢のシステムです！
そして、WSLには、ふつうのWSLとWSL2と呼ばれる二種類があります。
linuxが使えるという点では両者ともに、変わりません。
しかし、WSL2はHyper-Vという高速な仮想環境を用いており、WSLではできなかったことがいくつかできるようになっています。その中の一つにDockerが使えるという点があげられます(これで僕はwsl2の方を導入しようと決めました。もともとwindows10 proなら使えたのですが、homeの場合、virtualboxとか使わないといけないです。)
ということで、少し前置きが長くなりましたが、今回はWSL2を導入し、docker-compose upをするまでの流れと、詰まった点をご紹介します‼
注意
先ほども申し上げましたが、WSL2ではhyper-Vという仮想環境を用いているため、virtual-boxの様な仮想環境と共存できなくなるということにご注意ください！
今回の環境
OS:windows10 64bit home
CPU:AMD Ryzen 5大まかな手順
- windowsのバージョンアップ
- wsl1(もともとのwsl)を導入
- windows10 Preview Buildのインストールと諸々の設定
- 4. wsl1をwsl2に変換
- xserverの導入(任意)
- エディタの設定(VScode)
- dockerとdocker-comopseの導入
- docker-compose up!
1.windowsのバージョンアップ
僕のwindowsはバージョンが1700番台だったので、まず、バージョンを手動で上げる必要がありました。
(これ知らずに1時間ぐらい消えました涙)バージョンアップの方法はこの記事が詳しいので参考にしつつ、最新版にアップデートしてください。
結構時間がかかりますので、ご注意を2.wsl1を導入
まず最初にwsl1を導入します。
すでに導入済みの人はこの工程はスキップしていただいてかまいません。wsl1の導入方法は以下の通りです。
0.「プログラムと機能」からWindowsの機能の有効化または無効化のところに行き、「Windows Subsystem for Linux」を✓
1.Microsoft storeというアプリ(windows10標準装備)でwslと検索
2.Linux on Windows? 本当です。をクリックして、自分の入れたいディストリビューションを選択してインストールかんた～ん
3.Windows10 preview Buildのインストールと諸々の設定
以下の手順でWindows10 Preview Buildをインストールします。
(WSL2の正式リリースは今年5月といわれているので、現在は先行の不安定なバージョンのみです)1.デスクトップ画面の左下検索欄に設定と打って、設定アプリを開き、更新とセキュリティ→「Windows Insider Program」と行きます。
2.あとは基本推奨通りに進めればいいのですが、一つ注意！insiderはファーストを選択しましょう
3.再起動とwindows updateの繰り返し(ひたすら待つ)
4.戻ったら、また、検索欄でwinverと検索し、ヒットしたアプリを立ち上げる→OSのビルドが18917以上であればおっけ！
5.検索欄にpowershellと入力して、powershell(管理者権限)を起動。以下コピペして実行
Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform
6.再起動して、powershell(管理者権限)で次のコマンドでwsl1をwsl2に変換
wsl --set-version Ubuntu 2
(これ結構時間かかります。僕はだいたい1時間ほどかかりました！)以上でwsl2の導入は完了です。
4.Xserverの導入
ここは、web開発の人は飛ばしていただいて大丈夫です。
僕の場合、WSL2でGUIの開発がお仕事であったので、そういう場合にはXserver必要です。
この記事がめっちゃわかりやすいですただ、上の記事では当たり前すぎて省略されていますが、DisplayPORTの環境変数設定で
bashrcやzshrcをいじった後は、再起動するか
$ source ~/.bashrc
するなどして、設定を読み込んであげないといけません。5.エディタの設定(今回はVScodeを使用)
wsl2から
$code .
でVScodeを起動できるようにしたかったのですが、ここでも詰まってしまいました。手順
1.Vscode公式ページからVscodeをダウンロード
2. ダウンロードしたインストーラーを起動して、エンター押しまくって普通にインストール(途中PATHを自動的に追加する項目のチェックボックスがあるのでそこだけは必ず✓しておきましょう)
3. 拡張機能からRemote developmentを入手。
4. wsl2に入って適当なディレクトリで、code .で起動(もしもうまくいかない場合はインストールでPATHが通っていないので、自力でPATHを通すか、WSL上にVScodeを手動でインストールする必要があります(後述))これでうまくいく人もいます。
僕はうまくいきませんでした。うまくいかなかった(wsl上で
codeコマンドが使えない)時はwslとvscodeを使うにはPATHがちゃんと通っていることが必要です。
普通にやっていれば、
WindowsにWSLを導入した時点でクリアしてますですがもしもうまくいかなければ以下の対処法をお試しください。
PATHが通っていないとき
1. 「Windowsボタン」でスタートメニューを開き、Vscodeを探す。
2. Vscodeが見つかったら右クリック→その他→ファイルの場所を開く
3. エクスプローラーが開くのでアドレスバーを右クリックして「アドレスをテキストとしてコピー」を選択
4.あとは(このページ)[https://www.atmarkit.co.jp/ait/articles/1805/11/news035.html]を参考にPathの追加を行う。先ほどコピペしたアドレスを追加する。Remote Developmentが使えない(未解決)
上でご紹介した拡張機能Remote Developmentですが、ぼくは使えなかったです。
具体的には、wsl2上でshellからcode .を実行したのですが、以下の様なエラーが出てしまい開けませんでした。
VS code Server for WSL closed unexpectedly.この問題を解決しようといろいろ調べて、公式のgithubのissueでも未解決っぽかったので、別の解決策を試しました。
VScodeのダウングレード
どうやら最新版のVScodeだとRemote Developmentが必ず有効になってしまい、上のエラーが出てしまうようなので、ダウングレードして回避します。
1.現在入ってるVScodeのsettings.jsonに以下2行を適当に追加
"update.channel":"none",
"update.mode": "none",2.現在入っているVScodeをアンインストール
コントロールパネルからアンインストールしてください。
3.旧バージョンのVScode(1.33) のダウンロードとインストール
公式ページからダウンロードして下さい。
あとは先ほどのVScodeのインストールと手順は同じです！
7.dockerとdocker-compose up
今回は参考としてこちらのリポジトリをdockerで環境構築していきたいと思います。
1.gitの導入
普通に入ります。参考ページ2.dockerとdocker-composeの導入
インストール以下コピペ$sudo apt update $sudo apt upgrade -y $sudo apt install apt-transport-https ca-certificates gnupg-agent $software-properties-common curl -y $curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add - $sudo add-apt-repository "deb [arch=amd64] $https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" $sudo apt update $sudo apt install docker-ce docker-ce-cli containerd.io docker-compose -yでは早速docker-compose upしていきましょう！
$ git clone git@github.com:Dragon-taro/calender-app.git $ #sshでやりましたが、特に今回はpushもpullもしないので、httpsでも大丈夫です。 $ cd calender-app $ make $ sudo docker-copose up上で立ち上がるはずです。
ちなみにですが、毎回sudoつけて実行するのが面倒で、dockerをuserグループに入れたのですが、なぜか知らないですが、docker起動時に以下の様なエラーが出てしまいます。ERROR: Couldn't connect to Docker daemon at http+docker://localhost - is it running? If it's at a non-standard location, specify the URL with the DOCKER_HOST environment variable.sudoつけたら一応回避できます。どなたかご存じの人いたら教えて下さい。
以上になります！
それでは素晴らしいWSL2ライフを送ってください！
コメント等々ご指摘いただけると、当記事の改善にもつながりますので、不備不足ありましたらコメントしていただけると嬉しいです。
- 投稿日：2020-02-06T08:18:00+09:00
docker compose run とdocker compose execの違い ( #docker )
exec
- docker-compose up などで起動しているコンテナを利用する
- 起動中の docker コンテナがないと実行できない
- 同じコンテナに接続するのでコマンド履歴が残っている
- おおむね高速
docker-compose exec <service_name> bashrun
- コンテナを新しく作って実行する
- docker-compose up などで コンテナが起動していなくても利用できる
- 新しいコンテナに接続するのでコマンド履歴は残っていない
- おおむね低速
- docker コンテナ同士がうまく連携するように、依存関係を考慮して compose ファイルが書かれていないと、思わず動かない処理があったりするかもしれない
docker-compose run <service_name> bashOriginal by Github issue
- 投稿日：2020-02-06T01:52:57+09:00
syslog受信 → S3保存 してくれるDockerコンテナ お手軽セット
https://github.com/yagrush/docker-td-agent-syslog-to-s3
↑成果物は、こちらへどうぞ！実現したかったこと
syslogをS3に勝手に保存してくれる環境を、簡単に量産できるようにしたい！
作ったもの概要
ポート514にsyslogを送ると S3にgzipで1時間毎に保存してくれるDockerコンテナが、すぐ作れます。
（実際は、Dockerコンテナの中で td-agent が常駐しています）必要なもの
syslogを保存するS3バケット
S3バケットにアクセス権限を持つIAMユーザー
docker,docker-composeが入ったEC2インスタンスAmazon Linux release 2 (Karoo) で動作確認済。
ポート514の受信許可（セキュリティグループの設定）もお忘れなく。→ 必要でしたら こちら（AWS EC2 AmazonLinux2 のdockerホスト用初期設定）もご参照下さい。
使い方
詳細部分は README.md をご参照頂ければと思いますが、
全体的な流れも含めてざっくり説明しますと…
- S3に、syslogを保存するためのバケットを作成。
- そのバケットに書き込む権限を持つIAMユーザーを作成。
- そのIAMユーザーのアクセスキーとシークレットをダウンロードしておく。
- DockerホストとなるEC2インスタンスを作成。
- そのインスタンスがポート514でsyslogを受信できるようセキュリティグループを設定しておく。
- そのインスタンスにSSHで接続。
docker,docker-composeをインストールしてセットアップする。- 本成果物をダウンロードする。（gitとかcurlなどで。）
- 中のディレクトリに
cdする。.env.templateを.envにリネーム。.envを編集する。（S3に接続するための設定を書く。）- （保存間隔やファイル名のカスタムなどは、td-agent.conf をお好みで編集。）
- Dockerイメージをビルドする。
docker-compose build- イメージからコンテナを起動する。
docker-compose up -d- 余裕があれば、動作テストなどしておく。
- syslog送信側端末にて、送信先を上記のインスタンスのポート514に設定！
ミソ
1: .env から S3接続設定を拾って Dockerfile 内で（ビルド中に）使う
今回、S3接続設定を td-agent.conf から外出し（.env）したのですが、これができるまで結構ハマりました・・・
外部ファイルから docker-compose.yml 内で値を拾うことは割とすんなりできたのですが、
環境変数として
- docker-compose.yml 内の environment で渡し、
- Dockerfile 内の ENV で拾う
でビルド中に渡そうとしても、どうにもできず・・・
どうやらその方法では、コンテナが起動した後でないと有効にならないそうでした。
（起動後、コンテナ内のシェルに繋いでenvすると、間違いなく設定されてはいるのですが・・・）で、アンサーはというと
- docker-compose.yml 内の args で渡し、
- Dockerfile 内の ARG で拾う
これで、Dockerfile内で
$HOGE_HOGEで利用可能には、なりました。が・・・2: td-agent.conf 内で使う
しかーし！
今度は、td-agent.conf 内で環境変数として引用${ENV{'HOGE_HOGE'}}できない・・・Dockerfile 内でわざわざ ARG → ENV で拾い直してもダメ・・・
どうやら、今回 td-agent を Docker内のサービス（デーモン）として起動する仕組みにした影響っぽく。
工数的限界もあり、ここはゴリ押しでsedで置換する方法にしました
- 投稿日：2020-02-06T00:15:08+09:00
Windows10 HomeにDocker for Windowsをインストールする
https://download-stage.docker.com/win/edge/41944/Docker%20Desktop%20Installer.exe
上記の
Docker Desktop Installer.exeがWindows Home(WSLが有効)にインストールできることを確認した。
docker run hello-worldが動作することも確認した。URL的にStage版のedgeかと思うので、正式版はもうすぐリリースされるのではないかと思う。
参考
- https://github.com/docker/for-win/issues/4378#issuecomment-573062762 (2月上旬にはedgeをリリースすると説明されている)
- https://github.com/docker/for-win/issues/4586#issuecomment-577294824 (Windows Homeで動くDocker for Windowsのリンク元)