blackfireとは パフォーマンスプロファイリングサービスです。 関数がどの経路で読み込んでいて、 どのくらい処理に時間がかかり、 どのくらいメモリを使用しているのか、 目視で確認できるので、アプリケーションのパフォーマンス向上などに使用します。 用意するもの docker（念の為最新にしておきましょう） blackfireのアカウント（ここから作れるよ！） chrome(拡張機能も使うので入れておく) 挫けない心 環境を構築していく docker-compose.yml blackfire: image: blackfire/blackfire ports: ["8707"] environment: BLACKFIRE_SERVER_ID: {サーバーキー} BLACKFIRE_SERVER_TOKEN: {サーバートークン} BLACKFIRE_CLIENT_ID: {クライアントキー} BLACKFIRE_CLIENT_TOKEN: {クライアントトークン} サーバーキー・トークン、クライアントキー・トークンは、blackfireのマイページから確認できます。 Dockerfile RUN version=$(php -r "echo PHP_MAJOR_VERSION.PHP_MINOR_VERSION;") \ && curl -A "Docker" -o /tmp/blackfire-probe.tar.gz -D - -L -s https://blackfire.io/api/v1/releases/probe/php/alpine/amd64/$version \ && mkdir -p /tmp/blackfire \ && tar zxpf /tmp/blackfire-probe.tar.gz -C /tmp/blackfire \ && mv /tmp/blackfire/blackfire-*.so $(php -r "echo ini_get ('extension_dir');")/blackfire.so \ && printf "extension=blackfire.so\nblackfire.agent_socket=tcp://blackfire:8707\n" > $PHP_INI_DIR/conf.d/blackfire.ini \ && rm -rf /tmp/blackfire /tmp/blackfire-probe.tar.gz 用意していたDockerfileに追記する形で問題ありません。 また、すでに構築ずみの環境でしたら、buildし直しましょう。 $ docker-compose buide --no-cache $ docker-compose up -d これで環境は問題なくできるはずです。 blackfileの使い方 計測したいページを開きます。（ローカル環境でも大丈夫です。） 拡張機能のblackfire profilerを起動し、profile!ボタンを元気よくクリックすれば計測してくれます。 結構待ちますが、終わったらView Call Graphをクリックで、ページ遷移し詳細がみれます。 使ってみた感想 当環境が、Laravelを使っています。 サービスプロバイダーやミドルウェア、ビジネスロジック、Collection操作などの見直しに便利だったなぁと思いました。 SQLチューニングも行ったのですが、blackfireはあくまでロジックの精査に使用し、SQLに関してはdebugbarなどで確認しました。 日々の開発の中でなかなか最高パフォーマンスを出しながら開発するのも難しいですが、気づいたらめっちゃ遅い！とかなると思うので、タイミング見てパフォーマンスを気にしながら進めるもの重要だなと実感しました。

産業機械業界で働いているプロセスエンジニアのデータ解析環境を公開します。 プロセスエンジニアに必要なツール モデルが異なる実験を数多くする インタラクティブなデータ解析 過去の実験データを使えると好ましい モデル管理 データベース活用 生データをグラフにして報告する機会が多い 可視化アプリ データ解析環境の概要 上記を満たす環境を以下のコンテナを用意して Docker compose でデプロイします。 - データ解析: jupyterlab - モデル管理: mlflow - データベース: mysql - 可視化アプリ: streamlit ディレクトリ構成 . ├── Read.md ├── db │   └── data ├── docker │   ├── jupyter │   │   └── Dockerfile │   ├── mlflow │   │   └── Dockerfile │   └── streamlit │   └── Dockerfile ├── docker-compose.yml ├── etc │   ├── cookiemamama.yaml │   ├── exp │   ├── my.cnf │   └── requirements_simple.txt ├── mlruns ├── projects │   └── experiment1 └── struns └── main.py 実験ディレクトリは cookiecutter/datascience を用いて生成します。exp_name/notebook にノートブック、exp_name/src にスクリプト、exp/data/raw にデータを配置します。 experiment1 ├── LICENSE ├── Makefile ├── README.md ├── data │   ├── external │   ├── interim │   ├── processed │   └── raw ├── docs │   ├── Makefile │   ├── commands.rst │   ├── conf.py │   ├── getting-started.rst │   ├── index.rst │   └── make.bat ├── models ├── notebooks ├── references ├── reports │   └── figures ├── requirements.txt ├── setup.py ├── src │   ├── __init__.py │   ├── data │   │   ├── __init__.py │   │   └── make_dataset.py │   ├── features │   │   ├── __init__.py │   │   └── build_features.py │   ├── models │   │   ├── __init__.py │   │   ├── predict_model.py │   │   └── train_model.py │   └── visualization │   ├── __init__.py │   └── visualize.py ├── test_environment.py └── tox.ini Docker-compose ファイル docker-compose.yml version: '3' services: db: container_name: mysql command: --default-authentication-plugin=mysql_native_password environment: - MYSQL_DATABASE=analysis_db - MYSQL_ROOT_PASSWORD=root - MYSQL_USER=docker - MYSQL_PASSWORD=docker - TZ=Asia/Tokyo image: mysql:8.0 platform: linux/x86_64 ports: - "3306:3306" restart: always volumes: - ./db/data:/var/lib/mysql - ./etc/my.cnf:/etc/mysql/conf.d/my.cnf jupyter: build: context: . dockerfile: ./docker/jupyter/Dockerfile command: jupyter lab --ip=0.0.0.0 --port=8080 --allow-root --no-browser --NotebookApp.token="" container_name: jupyterlab depends_on: - mlflow - db ports: - "8080:8080" restart: always volumes: - ./projects:/home/projects mlflow: build: context: . dockerfile: ./docker/mlflow/Dockerfile command: mlflow server --backend-store-uri /home/mlruns --host 0.0.0.0 --port 5000 container_name: mlflow ports: - "5000:5000" restart: always volumes: - ./mlruns:/home/mlruns streamlit: build: context: . dockerfile: ./docker/streamlit/Dockerfile command: streamlit run struns/main.py container_name: streamlit depends_on: - db ports: - "8501:8501" volumes: - "./struns:/usr/src/app/struns" Docker ファイル jupyterlab pip で統一したかったので python ベースイメージを用いました。 python:3.x-slim, -slim-buster では jupyterlab がインストールできなかったので、-busterを使っています。 etc/cookiemamama.yaml は cookiecutter の設定ファイルです。 etc/exp は cookiecutter の設定ファイル実行するためのシェルスクリプトです。 jupyterlab==1.7.0 ではjupyter server extension disable nbclassicを実行しないと起動しないようです。 docker/jupyter/Dockerfile FROM python:3.8.10-buster MAINTAINER mamamaJohn USER root WORKDIR /home/projects COPY etc/requirements_simple.txt /tmp/requirements_simple.txt COPY etc/cookiemamama.yaml /home/cookiemamama.yaml COPY etc/exp /usr/local/bin/exp RUN chmod 777 /usr/local/bin/exp RUN pip install --upgrade pip setuptools && \ pip install -r /tmp/requirements_simple.txt RUN jupyter server extension disable nbclassic mlflow ベストプラクティスには、プロセスごとにコンテナを分割するべきと書かれています。 jupyterlabコンテナでmlflowを起動させずに、別コンテナでmlflowを起動することにしました。 docker/mlflow/Dockerfile FROM continuumio/miniconda:4.5.4 MAINTAINER mamamaJohn USER root WORKDIR /home RUN pip install --upgrade pip && \ pip install mlflow streamlit mysqlのデータを可視化できるように ORM ライブラリの dataset をインストールしています。 /struns/main.py でアプリを立ち上げます。 docker/streamlit/Dockerfile FROM python:3.8 MAINTAINER mamamaJohn USER root WORKDIR /usr/src/app RUN pip install --upgrade pip setuptools && \ pip install streamlit pandas numpy matplotlib dataset mysqlclient 導入手順 github から Development をクローンします。 git clone https://github.com/mamama039356/Development.git docker-compose.yml でコンテナを生成します。 cd Development docker compose up -d projects 下で exp を入力して repo_nameで "project/expname" を入力します。2回目以降は project 下で exp を入力します。 data/raw にデータを配置します。 src/ にスクリプトを配置します。 notebook に参考となるノートブックを配置します。 localhost:8080でjupyterlab, localhost:5000でmlflow, localhost:8501でstreamlitに繋がります。

DBをMysql(Docker)にしたい ローカルにLaravelのアプリを作成し、DBだけDockerのMysqlを使用したい。 まずは下記に習ってdocker imageを取得 参考URLhttps://mmtomitomimm.blogspot.com/2018/04/docker-mysqldb.html Docker Desktopで確認するとlatestが入っている。 laravelアプリ内にdocker-compose.ymlファイルを作成 sampleapp 　├──docker-compose.yml docker-compose.yml version: "3" services: mysql: # imageの指定 image: "mysql" # 環境変数の設定 environment: - MYSQL_DATABASE=mydatabase - MYSQL_USER=myuser - MYSQL_PASSWORD=mypassword - MYSQL_ROOT_PASSWORD=mypassword 下記のコマンドで立ち上げ $ docker-compose up $ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 3e317f73049c mysql "docker-entrypoint.s…" About a minute ago Up About a minute 3306/tcp, 33060/tcp sampleapp_mysql_1 passwordを求められるdocker-compose.ymlに書いてあるpasswordを入力して進む $ docker exec -it sampleapp_mysql_1 sh # mysql -u root -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 8 Server version: 8.0.24 MySQL Community Server - GPL Copyright (c) 2000, 2021, Oracle and/or its affiliates. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. mysql> show databases; +--------------------+ | Database | +--------------------+ | information_schema | | mydatabase | | mysql | | performance_schema | | sys | +--------------------+ 5 rows in set (0.01 sec) 参考URL

正常にDBコンテナは動いているのにLaravelでは接続できない！ 結構この罠に引っかかる人多いんじゃないかなと思って書きました。 環境 Laravel8 docker-compose 3.8 エラー(Laravel) SQLSTATE[08006] [7] could not connect to server: Connection refused Is the server running on host "127.0.0.1" and accepting TCP/IP connections on port 5432? 直接DBには接続できる 解決策 Laravelのデフォルトのdbホストが127.0.0.1になっています。 dbクライアント(tableplus)で繋がるんだから、なんかこれでいけそうな気がするんですけど、無理です。 →理屈は分からないのでわかる方教えてくだせえ！ env $ docker-compose ps Name Command State Ports ------------------------------------------------------------------------------------ api_project_app_1 docker-php-entrypoint php-fpm Up 0.0.0.0:19000->9000/tcp api_project_db_1 docker-entrypoint.sh postg ... Up 0.0.0.0:5432->5432/tcp api_project_web_1 /docker-entrypoint.sh ngin ... Up 0.0.0.0:80->80/tcp DBコンテナのホスト名をLaravelの.envに。 DB_HOST=127.0.0.1 ↓ DB_HOST=api_project_db_1 これでいけます

アプリケーション用DBとユニットテスト用のDBを分けたいときがあると思います よく見かける手法がユニットテストをインメモリDBとして立ち上げてそこでデータを投入する方法です 今回は、インメモリDBではなく、通常使用するようなDB(オンディスクDBと呼ばれるらしい)でユニットテストの時だけ切り替える方式です 前提 Doker環境で二つのmysqlを立ち上げます 二つどうやって立ち上げるかわかない方はこちらの記事を参照してください 結論 テストDB用のドライバーを設定 ユニットテスト実行時に、そのドライバーを指定 設定方法詳細 テストDB接続用のドライバーを設定する LaravelがテストDBに接続できるようにドライバーを設定します config/database.php 'test_mysql' => [ 'driver' => 'mysql', 'host' => 'test_mysql', 'port' => '3306',//ここが3307だと繋がらない。なんで？ 'database' => 'your_test_db', 'username' => 'user', 'password' => 'password', 'unix_socket' => '', 'charset' => 'utf8mb4', 'collation' => 'utf8mb4_unicode_ci', 'prefix' => '', 'prefix_indexes' => true, 'strict' => false, 'engine' => 'InnoDB', 'options' => array_filter([ PDO::MYSQL_ATTR_SSL_CA => env('MYSQL_ATTR_SSL_CA'), ]), ], phpunitの実行時のDBドライバーを変更 ユニットテストを実行したときだけテストDBを読み込むようにドライバーを指定します phpunit.xml //before //<server name="DB_CONNECTION" value="mysql"/> //after <server name="DB_CONNECTION" value="test_mysql"/> 疑問 config/database.phpでportをデフォルト3306にしないと接続できないのはなぜなんだろう。。。 dockerでテスト用DBは3307にしていて、phpmyadminでは3307で接続できているのに 誰か知っていたらコメントなどで教えてください 　宣伝 ツイッターもやってます 技術や製品開発に関する事などを呟いてますので、フォローお願いします https://twitter.com/wkyIghw8MlLpyJE

Alibaba CloudのシニアオフィサーであるDaonongが、Kubernetesの基本的なネットワークモデルの起源、進化、メリット、デメリットについて概要を説明します。 著者：アリババクラウドのシニアテクニカルエキスパートDaonong氏 この記事では、Kubernetesの基本的なネットワークモデルについて説明します。この記事は以下の部分に分かれています。(1) コンテナネットワーク開発の歴史を振り返り、Kubernetesのネットワークモデルの起源を分析、(2) Flannel HostGWの実装を探り、コンテナからホストにルーティングされる際にパケットがどのように変換されるかを示し、(3) ネットワークと密接に関係するサービスの仕組みや使い方を紹介し、簡単な例を挙げてサービスの仕組みを説明します。 Kubernetesネットワークモデルの進化 コンテナネットワークは、Dockerのネットワークが起源です。Dockerでは、内部ブリッジと内部で予約されたIPアドレスからなる比較的シンプルなネットワークモデルを採用しています。この設計では、コンテナネットワークは仮想化され、外部ネットワークから切り離されているため、ホストのIPアドレスやリソースを占有することはありません。コンテナネットワークは、ノードのIPアドレスにSNAT（Source Network Address Translation）を適用することで、外部のサービスにアクセスすることができます。コンテナは，宛先ネットワークアドレス変換（DNAT）によって外部にサービスを提供することができます。具体的には、ノード上でポートを有効にし、iptable などを介してコンテナのプロセスにトラフィックを誘導します。 このモデルでは、外部ネットワークは、コンテナネットワークとそのトラフィックを、ホストネットワークとそのトラフィックから区別することができません。例えば、172.16.1.1と172.16.1.2というIPアドレスを持つ2つのコンテナ間で高可用性を実現するためには、それらのコンテナをグループに割り当てて外部にサービスを提供する必要があります。しかし、2つのコンテナは外部からは同じものに見え、IPアドレスはホストポートに由来するため、この操作は困難です。 この問題を解決するために、Kubernetesでは機能の集合体である各PodにID（アイデンティティ）を割り当てています。このIDは、TCP（Transmission Control Protocol）スタックのIPアドレスです。 各Podは特定のIPアドレスを持ちます。このIPアドレスがどのように導かれるかは、外部ネットワークには関係ありません。このPodのIPアドレスへのアクセスは、Podのサービスへのアクセスと同等です。アクセス処理中にIPアドレスが変換されることはありません。たとえば、送信元IPアドレス10.1.1.1のアクセス要求が、送信元IPアドレスではなくホストIPアドレスであるIPアドレス10.1.2.1のPodに送信されたとします。これは許可されていません。PodはIPアドレス10.1.2.1を内部で共有し、機能集約を行ったコンテナをアトミックモードでデプロイできるようにしています。 コンテナをどのようにデプロイするのでしょうか？ Kubernetesはモデルの実装に制限を設けていません。アンダーレイネットワークを介して外部ルータを制御することでトラフィックを誘導することができます。デカップリングを実装するには、オーバーレイネットワークを利用して、アンダーレイネットワークの上にネットワークを重ねることができます。目標は、モデルの要件を満たすことです。 Podはどのようにしてオンラインになるのか？ コンテナネットワークでは、パケットはどのように伝送されるのでしょうか？ この疑問は、次の2つの側面を考慮することで解決できます。 プロトコル ネットワークトポロジー 第1の側面はプロトコルです。 プロトコルの概念は、TCPスタックの概念と同じで、下から順にレイヤ2、レイヤ3、レイヤ4で構成されています。パケットは右から左に向かって送信されます。アプリケーションデータはパケットにカプセル化され、TCPまたはUDP（User Datagram Protocol）のレイヤー4に送られた後、下位のレイヤーに送られます。パケットにはIPヘッダーとMACヘッダーが付加されてから送信されます。パケットは送信時とは逆の順序で受信されます。MAC ヘッダーと IP ヘッダーは、順番にパケットから取り除かれます。Rxポートは、プロトコルIDに基づいて、パケットを受信する必要のあるプロセスを探します。 2つ目の側面は、ネットワークトポロジーです。 コンテナは2つのステップでパケットを送信します。(1) コンテナ空間（c1）からホスト空間（infra）にパケットを送信し、(2) ホスト空間からリモートエンドにパケットを転送します。 私の考えでは、コンテナネットワークは、パケット送信プロセスを3つの部分で実装しています。 最初の部分はアクセスで、コンテナがVeth+bridge、Veth+pair、MACVLAN、またはIPVLANを介してホストに接続し、パケットをホスト空間に送信します。Veth+bridgeとVeth+pairは古典的な接続モードですが、MACVLANとIPVLANは高度なカーネルバージョンでサポートされています。 2つ目はスロットリングです。パケット送信を制御するためのネットワークポリシーを実装するかどうかと、このポリシーをどのように実装するかを決定します。ネットワークポリシーは、データパスの主要なノードに実装する必要があります。フックがデータパスの外にある場合は、ネットワークポリシーは有効になりません。 3つ目はチャネル設定で、2つのホスト間でパケットを送信する方法を指定します。パケットはルーティングによって伝送されますが、ルーティングはBGP（Border Gateway Protocol）ルーティングとダイレクトルーティングに分けられます。パケットはルーティングによって伝送することができます。コンテナから相手側にパケットを送信するプロセスは、以下のようにまとめられます。(1) パケットがコンテナを離れ、アクセス層を経由してホストに到達。(2) パケットがホストのスロットリングモジュール（ある場合）とチャネルを通過してピアエンドに到達。 Flannel HostGW:ルーティングソリューション Flannel HostGWでは、各ノードが排他的なCIDRブロックを占有し、各サブネットがノードにバインドされ、ゲートウェイがローカルまたはcni0ブリッジの内部ポートに設定されます。Flannel HostGWは管理が容易ですが、ノード間のPodマイグレーションには対応していません。IPアドレスやCIDRブロックがすでにノードに占有されている場合、他のノードに移行することはできません。 前述の図は、Flannel HostGWのルートテーブル設定を示したもので、以下のように説明されています。 最初のエントリーはシンプルで、NIC(Network Interface Controller)の設定に必要なものです。デフォルトルートのソースIPアドレスとデフォルトデバイスを指定します。 2 番目のエントリーでは、サブネットのルールフィードバックを指定します。例えば、CIDRブロック「10.244.0.0」は24ビットのマスクを持ち、ゲートウェイアドレス「10.244.0.1」がブリッジに配置されているとします。このCIDRブロックの各パケットは、ブリッジのIPアドレスに送信されます。 3番目のエントリーでは、ピアエンドへのフィードバックを指定します。たとえば、前出の図の左のサブネットは、CIDRブロック10.244.1.0に対応しています。ホストのNICのIPアドレス（10.168.0.3）は、ゲートウェイIPアドレスとして使用できます。10.244.1.0のCIDRブロック宛のパケットは、10.168.0.3のゲートウェイを経由して転送されます。 パケットの送信方法について説明します。 例えば、IPアドレスが10.244.0.2のコンテナが、10.244.1.3にパケットを送信したいとします。そのために、コンテナはローカルでTCPまたはUDPパケットを作成し、相手のIPアドレス、送信元のMACアドレス（ローカルイーサネットのMACアドレス）、および相手のMACアドレスを指定します。デフォルトルートはローカルに設定され、cni0のIPアドレスをデフォルトゲートウェイアドレスとして使用します。相手のMACアドレスはこのゲートウェイのMACアドレスです。このようにして、パケットをブリッジに送ることができます。CIDRブロックがブリッジ上にある場合、パケットはMAC層で変換されます。 この例のIPアドレスはローカルCIDRブロックに属していないので、ブリッジはパケットをホストのプロトコルスタックに送って処理します。プロトコルスタックは、相手のMACアドレスを識別し、10.168.0.3をゲートウェイとして使用します。MACアドレス10.168.0.3はARP（Address Resolution Protocol）のスヌーピングによって得られます。このパケットは、プロトコルスタックの各層でカプセル化された後、ローカルホストのeth0インターフェースから、ピアホストのeth0インターフェースに送信されます。相手ホストのNICのMACアドレスは、図の右に示すDst-MACとして指定されています。 暗黙の制限があります。指定されたMACアドレス（Dst-MAC）は、相手側で到達可能でなければなりません。ただし、2つのホストがレイヤ2で接続されていない場合や、2つのホスト間にゲートウェイや複雑な経路が存在する場合は、到達不可能となります。このような場合、Flannel HostGWは適用できません。パケットが対向MACアドレスに到達すると、対向ホストは、パケットの宛先MACアドレスが対向MACアドレスと同じだが、パケットの宛先IPアドレスが対向IPアドレスではないことを発見します。そして、ピアホストはパケットをプロトコルスタックに転送し、パケットは再びルーティングされます。10.244.1.0/24宛のパケットは、10.244.1.1ゲートウェイに送られなければならないので、cni0ブリッジに到達します。対向ホストは、10.244.1.3にマッピングされたMACアドレスを見つけ、ブリッジを介してそのコンテナにパケットを送信します。 このように、パケットの送信処理は、レイヤー2とレイヤー3で行われます。パケットはレイヤ2から送信されてからルーティングされます。送信処理は単純です。パケットがVXLANトンネルを介してルーティングされている場合は、ダイレクトルートをピアのトンネル番号に置き換えます。 Kubernetesのサービスの仕組み Kubernetesのサービスでは、クライアント側でロードバランシングを実装しています。 仮想IPアドレス（VIP）から実在のサーバーIPアドレス（RIP）への変換は、NGINXやELB（Elastic Load Balancer）が判断することなく、クライアント側で行われます。 実装:バックエンドではPod群が機能を提供し、フロントエンドでは仮想IPがアクセスポータルとして定義されます。仮想IPアドレスは、DNSのドメイン名にマッピングされます。このドメイン名でアクセスすると、クライアントは仮想IPアドレスを取得し、実在のIPアドレスに変換します。サービスやPodの追加など、APIサーバーを通じてPodやサービスの変更を監視し、その変更をローカルルールやユーザーモードのプロセスに送信するKubernetesのネットワークプロキシ（kube-proxy）は、実装の中核であり、非常に複雑です。 LVSサービス ここでは、Linux Virtual Server（LVS）のサービスを開発する方法を説明します。LVSは、ロードバランシングのためのカーネルメカニズムを提供します。LVSはレイヤー4で動作し、iptableよりも優れたパフォーマンスを発揮します。 例えば、kube-proxyは、次の図のように、あるサービスの設定を取得します。このサービスは、クラスターのIPアドレスが9376番ポートにマッピングされており、コンテナの80番ポートにフィードバックを送ります。機能的には3つのPodが存在し、IPアドレスは10.1.2.3、10.1.14.5、10.1.3.8となっています。 このサービスでは、以下のステップを実行します。 ステップ1： VIPをローカルにバインドします（カーネルを欺くため）。 LVSはレイヤ4で動作し、IP転送には関係しないため、サービスはカーネルにVIPを持っていることを伝えます。サービスは、VIPが自分のものであると信じている場合にのみ、TCPまたはUDPレイヤにトラフィックを転送します。ステップ1では、サービスがVIPを持っていることを示すために、サービスはVIPをカーネルに設定します。カーネルにVIPを設定するには、「ip route」に「local」を追加するか、ダミーのデバイスを介してVIPを追加します。 ステップ2： VIP用のIPバーチャルサーバー（IPVS）を作成します。 このステップでは、VIPに対してロードバランシングを実装する必要があることを示します。配信ポリシーには以下のパラメータが含まれます。IPVSのIPアドレスは、クラスタのIPアドレスです。 ステップ3：IPVS用のリアルサーバーを作成します。 このリアルサーバーがサービスプロビジョニングのバックエンドとなります。例えば、前図の3つのPodのIPアドレスをIPVSに設定することで、PodとIPアドレスを1対1で対応させることができます。 kube-proxyも同様に動作しますが、kube-proxyはPodの変更も監視します。例えば、podの数が5つになると、ルールの数も5つになります。Podが死んだり、キルされたりすると、ルールの数が1つ減り、また、サービスがリボークされると、すべてのルールが削除されます。以上が「kube-proxy」の管理作業です。 内部ロードバランサーと外部ロードバランサー サービスは以下の4種類に分けられます。 クラスターIP クラスタには、多くのサービスのグループPodにバインドされた内部VIPがあります。ClusterIP はデフォルトのサービスタイプです。このタイプのサービスは、ノードまたはクラスター内でのみ使用できます。 NodePort NodePortタイプのサービスは、クラスターによる外部呼び出しのみを目的としています。これらのサービスは、サービスとポート番号を1対1でマッピングして、ノードのスタティックポートに展開できます。これにより、クラスター外部のユーザーは、<NodeIP>:<NodePort>を指定してサービスを呼び出すことができます。 LoadBalancer LoadBalancerは、クラウドベンダー向けの拡張インターフェースです。Alibaba CloudやAmazonのようなクラウドベンダーは、成熟したロードバランシングメカニズムを持っており、大規模なクラスタによって実装されている場合があります。クラウドベンダーは、LoadBalancerインターフェイスを通じてこれらのメカニズムを拡張することができます。LoadBalancerインターフェースでは、NodePortとClusterIPが自動的に作成され、クラウドベンダーはこれらにLoadBalancerを直接取り付けることができます。また、クラウドベンダーはPodのRIPをELBのバックエンドにアタッチすることもできます。 ExternalName このサービスタイプは、内部のメカニズムではなく、外部のデバイスに依存します。例えば、各サービスをドメイン名にマッピングすることで、ロードバランシングを外部から実装することができます。 以下はその例です。前述の図は、ClusterIPやNodePortなどの複数のタイプのサービスと、クラウドベンダーのELBを組み合わせた、柔軟でスケーラブルな本番対応のシステムです。 ClusterIPは、機能的なPodのサービスポータルの実装に使用されます。3種類のPodが存在する場合は、3つのサービスクラスターIPアドレスがこれらのPodのサービスポータルとして使用されます。サービスポータルはクライアント側で実装され、制御はサーバー側で以下のように実装されます。 IngressPodは，NodePortサービスのIPアドレスに対して，起動， 整理，公開されます。Ingressは、Kubernetesの新しいタイプのサービスです。IngressPodは基本的に同種のPodの集まりです。これにより、Kubernetesのタスクが完了します。 ポート23456を持つPodを宛先とするアクセスリクエストは、ingressサービスにルーティングされます。ingressサービスの背後には、サービスのIPアドレスとingressバックエンドを管理するコントローラがあります。その後、リクエストはClusterIPサービスに転送され、さらに機能的なPodに転送されます。クラウドベンダーのELBに接続する場合は、各クラスタノードのポート23456をリッスンするようにELBを設定することができます。ポート23456に存在するサービスは、実行状態のingressインスタンスとみなされます。 トラフィックは、外部のドメイン名に基づいて解析され、ELBに誘導されます。ELBはロードバランシングを実装し、NodePortモードでトラフィックをingressにルーティングします。最後に、イングレスはClusterIPモードでバックエンドの適切なPodにトラフィックをルーティングします。このシステムは、機能的に多様で堅牢です。システムの各リンクは単一障害点（SPOF）から解放され、管理とフィードバックを実装しています。 まとめ 今回の記事で学んだことをまとめてみましょう。 この記事では、Kubernetesのネットワークモデルの進化と、PerPodPerIPの目的について説明しました。 Kubernetesのネットワークモデルでは、上から順にレイヤー4からパケットが送信されます。パケットが相手側で受信されると、MACヘッダーとIPヘッダーがパケットから取り除かれます。このパケット送信プロセスは、コンテナネットワークにも適用できます。 ingressメカニズムは、サービス-ポートマッピングを実装し、クラスターの外部サービスプロビジョニングを設定することができます。本稿では、実現可能な導入例を示すことで、ingress、クラスタIPアドレス、PodIPアドレスなどの概念を関連付け、Kubernetesコミュニティで導入された新しいメカニズムやオブジェクトリソースを理解できるようにしています。 本ブログは英語版からの翻訳です。オリジナルはこちらからご確認いただけます。一部機械翻訳を使用しております。翻訳の間違いがありましたら、ご指摘いただけると幸いです。 アリババクラウドは日本に２つのデータセンターを有し、世界で60を超えるアベラビリティーゾーンを有するアジア太平洋地域No.1(2019ガートナー)のクラウドインフラ事業者です。 アリババクラウドの詳細は、こちらからご覧ください。 アリババクラウドジャパン公式ページ

TimeZoneを変更したくて試したが imageがpostgresql:13.2 だと、環境変数TZとPGTZの両方が必要だった。 version:"3" services: postgres: image:postgresql:13.2 environment: - TZ=Asia/Tokyo - PGTZ=Asia/Tokyo - POSTGRES_USER=xxxx - POSTGRES_PASSWORD=xxx - POSTGRES_DB=xxx postgres=# show timezone; TimeZone ------------ Asia/Tokyo (1 row)

dockerコンテナを作成してみる docker実行環境確認 dockerを使用したwebサーバを構築する dockerイメージを使用してnginxを動かす dockerコンテナを作成してみる ubuntuのイメージをもとにコンテナを作成・実行し、作成したコンテナでhelloworldを表示する $ docker container run ubuntu:latest echo 'Hello World' >>> Hello World すでにubuntuのlatest(最新のイメージ)が入っていたのでリポジトリからとってくるようなことはせずただhello worldを出力した docker実行環境確認 $ docker system info Client: Context: default Debug Mode: false Plugins: app: Docker App (Docker Inc., v0.9.1-beta3) buildx: Build with BuildKit (Docker Inc., v0.5.1-docker) compose: Docker Compose (Docker Inc., 2.0.0-beta.1) scan: Docker Scan (Docker Inc., v0.8.0) Server: Containers: 11 コンテナの数 Running: 1 Paused: 0 Stopped: 10 Images: 3 Server Version: 20.10.6 dockerのバージョン Storage Driver: overlay2 ストレージドライバーの種類 Backing Filesystem: extfs Supports d_type: true Native Overlay Diff: true userxattr: false Logging Driver: json-file Cgroup Driver: cgroupfs Cgroup Version: 1 Plugins: Volume: local Network: bridge host ipvlan macvlan null overlay Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog Swarm: inactive Runtimes: io.containerd.runtime.v1.linux runc io.containerd.runc.v2 Default Runtime: runc Init Binary: docker-init containerd version: 05f951a3781f4f2c1911b05e61c160e9c30eaa8e runc version: 12644e614e25b05da6fd08a38ffa0cfe1903fdec init version: de40ad0 Security Options: seccomp Profile: default Kernel Version: 5.4.72-microsoft-standard-WSL2 Operating System: Docker Desktop OSType: linux OSの種類 Architecture: x86_64 アーキテクチャ CPUs: 8 Total Memory: 9.237GiB Name: docker-desktop ID: ODNB:5MX5:6OBG:42MC:VNCR:OJJF:TP3E:D7WM:FMVK:5YUU:AK6W:HGLE Docker Root Dir: /var/lib/docker Debug Mode: false Registry: https://index.docker.io/v1/ Labels: Experimental: false Insecure Registries: 127.0.0.0/8 Live Restore Enabled: false WARNING: No blkio throttle.read_bps_device support WARNING: No blkio throttle.write_bps_device support WARNING: No blkio throttle.read_iops_device support WARNING: No blkio throttle.write_iops_device support docker system df ディスク利用状況 $ docker system df TYPE TOTAL ACTIVE SIZE RECLAIMABLE Images 3 3 120.1MB 5.613MB (4%) Containers 11 1 1.116kB 0B (0%) Local Volumes 1 1 10.32MB 0B (0%) Build Cache 32 0 396MB 396MB dockerを使用したwebサーバを構築する nginxを使用する $ docker pull nginx Using default tag: latest latest: Pulling from library/nginx f7ec5a41d630: Pull complete aa1efa14b3bf: Extracting 2.654MB/26.58MB b78b95af9b17: Download complete c7d6bca2b8dc: Download complete cf16cd8e71e0: Download complete 0241c68333ef: Download complete nginxイメージがダウンロードされている。 $ docker image ls REPOSITORY TAG IMAGE ID CREATED SIZE docker101tutorial latest f108ba0cc6df 2 hours ago 28MB meri100ht/docker101tutorial latest f108ba0cc6df 2 hours ago 28MB ubuntu latest 7e0aa2d69a15 2 weeks ago 72.7MB alpine/git latest c99c7d810bc1 3 weeks ago 25.1MB nginx latest 62d49f9bab67 4 weeks ago 133MB dockerイメージを使用してnginxを動かす 使用するイメージはnginxイメージ、 imagenginxを使ってwebserverという名前のdockerコンテナを起動。ブラウザからHTTP(80番ポート)でのアクセスを許可するために-pオプションでコンテナからの転送を許可している。 -p 80:80 -ホストのポート80をコンテナのポート80にマップします $ docker container run --name webserver -d -p 80:80 nginx 789a5e28f3d3199f2b59482f660c974fdb59455729dab113491786caeaf1c26f docker: Error response from daemon: driver failed programming external connectivity on endpoint webserver (499d03f5142f3b1f78970f8bf05b356afceff22744feab8a0d63c7c23d717c93): Bind for 0.0.0.0:80 failed: port is already allocated. $ docker container ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 01419f74cb77 docker101tutorial "/docker-entrypoint.…" 2 hours ago Up 2 hours 0.0.0.0:80->80/tcp, :::80->80/tcp docker-tutorial 多分さっきのチュートリアルで80番ポートを開けていたので、このコンテナを停止すればnginxでアクセスできそう $ docker container run --name webserver -d -p 80:80 nginx docker: Error response from daemon: Conflict. The container name "/webserver" is already in use by container "789a5e28f3d3199f2b59482f660c974fdb59455729dab113491786caeaf1c26f". You have to remove (or rename) that container to be able to reuse that name. See 'docker run --help'. さっきwebserverという名前でコンテナを作ってしまったので名前が重複している。 新しい名前のコンテナを作成 富永隼斗@LAPTOP-AE8Q620A MINGW64 /c/dockerlesson $ docker container run --name webserver1 -d -p 80:80 nginx 8cfddf61720d3c84a7695e903ef0ed1fa1d1477e2b8af5bdbf1289244eedd53f ちゃんと動いてるっぽい $ docker container ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 8cfddf61720d nginx "/docker-entrypoint.…" 34 seconds ago Up 31 seconds 0.0.0.0:80->80/tcp, :::80->80/tcp webserver1 コンテナを停止してみる 富永隼斗@LAPTOP-AE8Q620A MINGW64 /c/dockerlesson $ docker stop webserver1 webserver1 ちゃんとアクセスできなくなっていることが分かる コンテナを再起動 富永隼斗@LAPTOP-AE8Q620A MINGW64 /c/dockerlesson $ docker start webserver1 webserver1 繋がっていることはわかる

DockerDesktopで「No containers running」と表示され、Dockerが使えない 実行しようとした操作は、参照したオブジェクトの種類ではサポートされていません。 どうやらDocker側の問題ではなくWSL側の問題のようです。 NoLsp.exeをダウンロードして実行する PowwerShell(管理者権限で実行） curl www.proxifier.com/tmp/Test20200228/NoLsp.exe -o C:\Windows\System32/NoLsp.exe cd C:\Windows\System32 NoLsp.exe wsl.exe Success! 詳しくはmicrosoftのWSLレポジトリのissueを参考にしてください。 起動成功

技術者であるDeng Qingling氏は、ビジネス開発の観点から、サーバーレスのKubernetesとその運用についての考えを述べています。 著者：アリババのテクニカルエキスパート、Deng Qinglin (Qingling)氏 この記事は、アリババの技術専門家であるDeng Qinglin（青林）氏が作成した内部文書から転載したものです。彼は、Alibaba Cloud Consoleチームから、Serverless Kubernetesの基盤となるECI R&Dチームに異動し、その後、Kubernetesの勉強を始め、ビジネス開発の観点からKubernetesの登場と運用についての考えを語ってくれました。 はじめに 2019年の後半、私は新しい職場に異動し、Kubernetesの勉強を始めました。まだまだKubernetesへの理解は不完全ですが、学んだことの一部を紹介したいと思います。この記事が、皆さんがKubernetesを使い始める際に役立つことを願っています。もし、この記事に誤りがあれば、訂正しますので、ご連絡ください。 Kubernetesを紹介する記事はたくさんありますし、Kubernetesの公式ドキュメントも非常にわかりやすいです。ここでは、ビジネス開発の観点から、Kubernetesの登場とその運用についてお話したいと思います。 序章 中国では生活水準の向上に伴い、ほぼすべての家庭に自動車が普及しています。王さんは、今後5年間で車の廃棄ビジネスが急速に発展すると予測していました。2019年、政府は新政策「使用済み自動車リサイクル管理弁法」を発表し、自動車の廃車・リサイクルの「特殊産業」の地位を撤廃し、業界を市場ベースの競争に開放することになりました。 王さんは、これはビジネスを始めるのに良い機会だと感じ、興味を持った数人のパートナーを見つけ、Taoche.comというプラットフォームを作りました。 Taoche.comは当初、オールインワンのJavaアプリケーションを物理的なサーバーに展開していました。 ビジネスの成長に伴い、サーバーが対応しきれなくなったため、64c256gのサーバーから160c1920gのモデルにアップグレードしました。コストは少しかかりましたが、アップグレードしたサーバーで必要なシステムリソースを確保できました。 しかし、1年も経つと160c1920gでは足りなくなってきました。同社では、サービスを分割して分散展開する必要があり、分散展開の過程で発生した問題を解決するために、同社はHSF、TDDL、Tair、Diamond、MetaQなどの一連のミドルウェア製品を導入しました。この困難なビジネスアーキテクチャの変革の後、彼らはオールインワンのJavaアプリケーションを複数の小さなアプリケーションに分割することに成功し、我々はIBM、Oracle、EMCのインフラから脱却しました。 分散型アーキテクチャへの移行後、王氏のチームはより多くのサーバーを管理しなければならず、サーバーのバッチ、ハードウェアの仕様、OSのバージョンなどが混乱していました。これにより、アプリケーションのランタイムやO&Mにおいて様々な問題が発生しました。 仮想マシン技術を使うことで、基盤となるさまざまなハードウェアやソフトウェアの違いを保護することができます。ハードウェアの違いはあっても、アプリケーションから見ると同じように見えるのです。当時、仮想化はパフォーマンスを大幅に低下させていました。 一方、Dockerはどうでしょうか。Dockerは、cgroupなどのLinuxのネイティブな技術をベースにしているため、パフォーマンスへの影響が少なく、根本的な違いを保護することができます。これは本当に良い選択でした。また、Dockerイメージをベースにしたサービス提供は、継続的インテグレーションや継続的デリバリ（CI/CD）を非常に容易にします。 Dockerコンテナの数が増えるにつれ、企業はDockerコンテナ間のスケジューリングとコミュニケーションという新たな課題に直面することになりました。Taoche.comはもはや小さな会社ではありませんでした。何千ものDockerコンテナを動かしていたのです。現在のビジネスを続けていけば、すぐに1万個以上のコンテナを持つことになるでしょう。 彼らは、サーバーの管理（サーバーの健康状態、空きメモリ、CPUリソースのチェックなど）を自動的に行い、CPUやメモリの必要量に応じてコンテナ化に最適なサーバーを選択できるシステムを必要としていました。また、コンテナ間の通信を制御するシステムも必要です。例えば、ある部署のコンテナが、別の部署の社内サービスコンテナにアクセスできてしまうようなことがあってはなりません。このようなシステムを「コンテナオーケストレーションシステム」と呼びます。 コンテナオーケストレーションシステム まずTaocheは、"多数のサーバーを扱う場合、コンテナオーケストレーションシステムをどのように実装するか？"という質問に答えなければなりませんでした。 すでにオーケストレーションシステムを導入していると仮定して、サーバーの一部をオーケストレーションシステムの実行に使用し、残りのサーバーでビジネスコンテナを実行することになります。オーケストレーションシステムを稼働させるサーバーをマスターノード、ビジネスコンテナを稼働させるサーバーをワーカーノードと呼びます。 マスターノードはクラスターの管理を担当し、必要な管理インターフェースを提供する必要があります。このうち、管理者がクラスターのO&Mを行うためのインターフェースと、ワーカーノードとの間でリソースの割り当てやネットワークの管理などを行うためのインターフェースがあります。 マスターノード上で管理インターフェースを提供するコンポーネントを、我々は「kube-apiserver」と呼んでいます。一方、APIサーバとのやりとりには2つのクライアントが必要です。 クラスタのO&M管理者には「kubextl」が提供されます。 kubeletはワーカーノードに提供されます。 これで、クラスターのO&M管理者、マスターノード、ワーカーノードが相互にやりとりできるようになりました。O&M管理者は、kubectlを使って「Create 1,000 containers from the Taoche User Center v2.0 image」というコマンドを発行することができます。このリクエストを受け取ったマスターノードは、クラスタ内のワーカーノードのリソース情報に基づいて計算スケジューリングを行います。そして、マスターノードは、作成が必要な1,000個のコンテナに対応するワーカーノードを算出し、該当するワーカーに関連する作成要求を送信します。スケジューリングを担当するコンポーネントは「kube-scheduler」と呼ばれています。 マスターは、各ワーカー上のコンテナのリソース消費量や稼働状況をどのようにして知るのでしょうか。簡単に言うと、ワーカー上のkubeletクライアントを使って、ノードのリソースやコンテナの稼働状況を定期的に能動的に報告します。そして、マスターはこのデータを保存し、その後のスケジューリングやコンテナ管理に利用することができます。このデータを保存するには、ファイルやデータベースに書き込むことができます。また、データの一貫性や高可用性の要件を満たすことができる「etcd」というオープンソースのストレージシステムがあります。インストールも簡単で、性能も良好です。 すべてのワーカーノードとコンテナの運用データが手に入れば、それを使っていろいろなことができるようになります。前述の例では、Taoche User Center v2.0のイメージから1,000個のコンテナが作成されました。このうち5つのコンテナがワーカーノードAで稼働しているとします。ノードAが突然ハードウェア障害に遭遇して利用できなくなった場合、マスターノードは利用可能なワーカーノードのリストからノードAを削除します。次に、元々このノードで稼働していた5つのUser Center v2.0コンテナを、利用可能な他のワーカーノードに再割り当てする必要があります。これにより、システムはUser Center v2.0コンテナの数を1,000に戻すことができます。その後、コンテナが正しく通信できるように、コンテナのネットワーク通信構成を調整する必要があります。ここで、この作業に関わる一連のコンポーネントを「コントローラ」と呼びます。このコントローラには、ノードコントローラ、レプリケーションコントローラ、エンドポイントコントローラなどがあります。また、これらのコントローラを集中的に管理するランタイムコンポーネントとして「kube-controller-manager」が用意されています。 では、マスターがコンテナ間のネットワーク通信をどのように実装・管理しているかを見てみましょう。まず、各コンテナは、他のコンテナとの通信に使用される固有のIPアドレスを持つ必要があります。相互に通信する必要のあるコンテナは、異なるワーカーノード上で動作する場合があります。そのような通信には、ワーカーノード間のネットワーク通信が必要になります。そのため、各ワーカーノードは固有のIPアドレスを持つ必要があります。コンテナは、コンテナのIPアドレスを介して相互に通信し、ワーカーノードのIPアドレスを認識しないため、ワーカーノードはコンテナのIPアドレスに対するルーティング情報を提供する必要があります。そのためには、iptablesやIPVSなどの技術を利用します。コンテナIPアドレスやコンテナ数が変更された場合は、それに応じてiptablesやIPVXの設定を更新する必要があります。ワーカーノード上には、ルートフォワーディングの設定を聞き取り、調整する役割を担う特別なコンポーネントが必要です。このコンポーネントは「kube-proxy」と呼ばれます。 ここまでで、コンテナ間のネットワーク通信を解決しました。しかし、コーディングの際には、動的に変化する可能性のあるコンテナのIPアドレスではなく、ドメイン名やVIPでサービスを呼び出す必要があります。そのためには、コンテナのIPアドレスに加えて、サービスをカプセル化する必要があります。このサービスは、クラスタのVIPまたはドメイン名である可能性があり、そのためには、内部のDNS解決サービスが必要です。 すでにkubectlがあり、マスターと簡単にやりとりできますが、ウェブ管理インターフェースを追加することで、より簡単になります。また、クラスタ全体に関連するコンポーネントのコンテナリソースや運用ログを見たい場合もあります。 DNS、Web管理インターフェース、コンテナリソース情報、クラスタログなど、ユーザーエクスペリエンスを向上させることができるコンポーネントを総称して「プラグイン」と呼びます。 さて、ここまででコンテナオーケストレーションシステムの構築に成功しました。次に、本稿で紹介したコンポーネントを簡単にまとめておきます。 マスターコンポーネント：kube-apiserver、kube-scheduler、etcd、kube-controller-manager ノードコンポーネント：kubelet、kube-proxy プラグイン: DNS、Web UI、コンテナリソースモニタリング、クラスタログ これらは、Kubernetesにおける主要なコンポーネントです。 サーバーレスのコンテナオーケストレーションシステム Taoche社はコンテナオーケストレーションシステムの導入に成功し、満足していましたが、Taoche社の王社長（もはや単に王氏ではない）は、オーケストレーションシステムのR&DおよびO&Mコストが高すぎると考え、これらのコストを削減する方法を、そして社員がクラスターのO&M管理ではなく、事業開発に専念できるオーケストレーションシステムを探していました。王社長と同社の技術チームは、サーバーレスのコンセプトを知り、すぐに興味を持ち、サーバーレスのコンテナオーケストレーションシステムを構築できないかと考えました。 運良く、彼らはServerless Kubernetesという製品を発見しましたが、それはまた別の日の話です。 本ブログは英語版からの翻訳です。オリジナルはこちらからご確認いただけます。一部機械翻訳を使用しております。翻訳の間違いがありましたら、ご指摘いただけると幸いです。 アリババクラウドは日本に２つのデータセンターを有し、世界で60を超えるアベラビリティーゾーンを有するアジア太平洋地域No.1(2019ガートナー)のクラウドインフラ事業者です。 アリババクラウドの詳細は、こちらからご覧ください。 アリババクラウドジャパン公式ページ

docker desktop付属のチュートリアル＋α 特徴 使用までの流れ First, clone a repository Now, build the image Run your first container Now save and share your image docker desktop付属のチュートリアル＋α ※ この記事は「プログラマのためのdockerの教科書　第２版」からの引用が多く、自分のメモのために作成した記事です。 dockerのコマンドプロンプトではなぜかコピーができなかったので以下画像で対応。 特徴 複数のコンテナを組み合わせて1つのアプリケーションを構成するマイクロサービス型のアプリケーションと親和性が高い 使用までの流れ Dockerfileからイメージを取得または自分でイメージを作成 コンテナのひな型であるイメージをもとにコンテナを稼働させる dockerのイメージさえあれば同じ環境で開発ができるので、オンプレミス環境→クラウドや、クラウド⇔クラウドといったことも容易にできる。 First, clone a repository The Getting Started project is a simple GitHub repository which contains everything you need to build an image and run it as a container. Clone the repository by running Git in a container. docker run --name repo alpine/git clone https://github.com/docker/getting-started.git alpine/gitという名前のイメージがダウンロードされている。 dockerイメージとは、アプリケーションの実行に必要なプログラム・ライブラリ・ミドルウェア・OS・ネットワークの設定などを一つにまとめたファイルで、コンテナのひな型であり、その実態はアプリケーションの実行に必要なファイル群が格納されたディレクトリ。 Now, build the image A Docker image is a private file system just for your container. It provides all the files and code your container needs. dockerfileをビルドしてdockerfileに定義した構成のdockerイメージを作成している ↑文法的に一番後ろには.が必要だったっぽい。 ↓正常にビルドされた例 -t, --tag="" 書式 'name:tag' により名前および任意のタグを指定します やっていることを理解してみる。 dockerでビルドすると、ビルドを実行したディレクトリは以下のすべてのファイルがdockerデーモンに転送される。美都度を実行するディレクトリには十分注意する必要がある。 .dockerigonreでは、ビルドでdockerデーモンに転送したくないファイルを指定する。 load build definition requirements.txtをコピー 多分見つからなかったので、pip install 繰り返しになるが、dockerfileに記述されたコードを順に実行しているだけ。多分。 Run your first container Start a container based on the image you built in the previous step. Running a container launches your application with private resources, securely isolated from the rest of your machine. 実行後の文字はコンテナID。多分ハッシュ値で一意なコンテナを見つけるため docker101tutorialというイメージから docker-tutorialというコンテナを起動 -d バックグランドで実行するオプション -p ブラウザからhttp(80番ポート)でのアクセスを許可するために、コンテナからの転送を許可している dockerは一つのLinuxカーネルを複数のコンテナで共有している。コンテナ内で動作するプロセスを一つのグループとして管理し、グループごとにそれぞれファイルシステムやホスト名・ネットワーク名を割り当て、グループが異なればプロセスやファイルへのアクセスができない。この仕組みでコンテナを独立した空間として管理する。これを実現するのがLinuxカーネル技術(namespace,cgoups,etc...) Now save and share your image You must be signed in to Docker Hub to share your image. Sign in here. Save and share your image on Docker Hub to enable other users to easily download and run the image on any destination machine. docker tag docker101tutorialにユーザ名/docker101tutorialというタグを設定している。 google container registryにアップロードするときにはタグを設定しなければならないが、docker hubにイメージをアップロードするときも多分同様だからタグをつけている。 実際にdocker image lsするとユーザ名/docker101tutorialというタグが付いたイメージが作成されている。しかし、docker101tutorialというイメージと、イメージIDが全く一緒であるので、実態としては同じイメージである。リネームしたり、コピーしたりしたわけではない。 プロジェクトIDがmeri100htであるので、meri100htとしている。実際にdocker hubの自分のページを見に行くと、githubみたいにリポジトリ名をブラウザ上で決めていないのに、meri100htから始まるリポジトリ名となっている。

どうしてこの記事を書こうと思ったのか 自分専用のAI開発環境が欲しい！ きっと誰もが思うことでしょう。かくいう私も競馬AIを開発したいというモチベーションのもと、AI開発環境の構築で試行錯誤を繰り返しました。そしてこの度納得のいく環境を構築できたので備忘も含めて構築手順を残そうと思います。 今回はDockerとmlflowが主な技術要素なんですが、その理由はクラウドを意識したからです。もともとクラウドに構築したかったけど課金されるのは嫌だな→Dockerならクラウド移行が簡単だ、という思いからDockerを採用することにしました。そして、機械学習開発の課題の「実験結果の管理」と「学習済みモデルの管理」を解決するために、mlflowの導入を決めました。この環境を構想から構築するまでに3ヶ月ほど費やしたので、きっと同じ環境を作りたい人がいるだろうなと思い、この記事を執筆することにしました。 ※2021/5/12現在、記事は執筆中で順次コンテンツを増やしていく予定です。 今回構築する環境構成 今回構築する環境は、UIとしてWebブラウザ（Chromeなど）とVScodeを使い、ローカル環境にPython実行環境を構築し、コンテナ環境にデータベースや機械学習の実験モデル管理環境を構築しています。 この環境を構築することで、AIの開発から運用までスムーズに回すことができるようになります。 今回はMac上に環境を構築しましたが、anacondaもdockerもWindowsやLinux環境でも同様に構築できると思われます。（稼働確認は行なっていません） 環境構築手順 次のような流れで環境構築を行います。 [python実行環境構築] 1. ローカル環境にanacondaをインストールする 2. tensorflowをインストールする 3. optunaをインストールする 4. mlflowをインストールする [VScode環境構築] 1. ローカル環境にVScodeをインストールする 2. 拡張機能をインストールする [docker実行環境構築] 1. ローカル環境にdockerをインストールする 2. 分析用データ保存用MySQLとデータ参照用Adminerを設定する(docker-compose) 3. mlflowとデータベース・リポジトリを設定する（docker-compose） ※各手順の詳細は、別記事にて作成予定です。