コンテナ若葉マーク勉強会資料.pdf

© SIOS Technology, Inc. All rights Reserved. 世界⼀わかりみの深いコンテナ＆Docker⼊⾨ 2020年6⽉29⽇
武井宜⾏

© SIOS Technology, Inc. All rights Reserved. ハッシュタグ 2 Internal
Only #wakabamark

© SIOS Technology, Inc. All rights Reserved. About me 3
Internal Only BCPVUNF Noriyuki TAKEI ෢Ҫ ٓߦ Information • サイオステクノロジー株式会社 • クラウドネイティブアプリケーション • 千葉県在住 Favorites • Azure • Squash • Sweets blog https://tech-lab.sios.jp/ core skill Azure Kubernetes Service Docker

© SIOS Technology, Inc. All rights Reserved. コンテナとは︖ 5 Internal
Only ίϯςφͱ͸ʁ コンテナとは、平たく⾔ってしまえば、単なるプロセスです。

Only Կ͕Ͱ͖Δͷʁ OSの中にOSが⽴てられます。 $FOU04 ϗετ04 8FCαʔόʔ༻$FOU04 σʔλϕʔε༻$FOU04 ϑΝΠϧαʔόʔ༻$FOU04 似たようなのに仮想化ってあったような・・・。

Only Ծ૝Խͱͷҧ͍ ホストOS HyperVisor OS OS プロセスプロセスプロセスプロセス Docker Engine プロセスプロセスプロセスプロセス Ծ૝Խ ίϯςφ プロセスプロセスプロセスプロセスコンテナはOSが不要な分だけ⾼速︕︕

Only Ծ૝Խͱͷҧ͍ ホストOS HyperVisor OS OS プロセスプロセスプロセスプロセス Docker Engine プロセスプロセスプロセスプロセスプロセスプロセスプロセスプロセスカーネル Docker上のプロセスとホストOS上のプロセスはカーネルを共有します。

Only 以下のような2つのアプリケーションを⼀つのホストOS上に構築することを考えてみます。 var www html / <?php echo “hoge”; ?> ΞϓϦ app.phpの所有者は www-data(id=33) app.php var www html / <?php echo “fuga”; ?> ΞϓϦ app.phpの所有者は www-data(id=33) app.php

Only ホストOS HyperVisor OS var www html / <?php echo “hoge”; ?> ΞϓϦ app.phpの所有者は www-data(id=33) app.php OS var www html / <?php echo “fuga”; ?> ΞϓϦ app.phpの所有者は www-data(id=33) app.php 仮想化だったら簡単︕︕

Only ホストOS Docker Engine var www html / <?php echo “hoge”; ?> ΞϓϦ app.phpの所有者は www-data(id=33) app.php var www html / <?php echo “fuga”; ?> ΞϓϦ app.phpの所有者は www-data(id=33) app.php コンテナではどうやるの︖ ユーザー名かぶってるしファイル名かぶってるし

Only そこでコンテナでは超重要な概念であるの出番です。 namespace

Only OBNFTQBDFͱ͸ʁ プロセス、ファイル構造、ユーザーID、グループIDなどを⼀つのOSの中で分離する技術である。プログラム⾔語の中ではよく登場する概念である。Javaのパッケージと⾔う概念とにているものがあり、同⼀の名称を使いたい場合(例えばUser.java)、namespace を分けると実現可能となる。 package jp.sios.funcA User.java package jp.sios.funcB User.java コンテナのコアテクノロジーであるnamespaceという技術は2006年あたりにLinux カーネルに実装された技術であり、最新の技術ではない。

Only ホストOS apache(親) apache(⼦) apache(⼦) pid 1 / www html ファイルシステム initプロセス pid 2 プロセス namespace A apache(親) apache(⼦) apache(⼦) / www html プロセスファイルシステム pid 1 pid 3 namespace B pid 2 pid 3 pid 2 pid 3 namespaceが異なれば同じファイル名やディレクトリが⼀つのOS上に作れる。 pid 1

Only ホストOS apache(親) apache(⼦) apache(⼦) pid 1 / www html ファイルシステム initプロセス pid 2 プロセス namespace A apache(親) apache(⼦) apache(⼦) / www html プロセスファイルシステム pid 1 pid 1 pid 3 namespace B pid 2 pid 3 pid 2 pid 3 このnamespace で区切られた部分がコンテナ

Only では namespace(コンテナ) を作ってみよう

Only # ps ax PID TTY STAT TIME COMMAND 1 ? Ss 0:03 /sbin/init 2 ? S 0:00 [kthreadd] 4 ? I< 0:00 [kworker/0:0H] 6 ? I< 0:00 [mm_percpu_wq] 7 ? S 0:00 [ksoftirqd/0] 8 ? I 0:01 [rcu_sched] ………… # unshare --mount-proc -p --fork /bin/bash # ps ax PID TTY TIME CMD 1 pts/0 00:00:00 bash 11 pts/0 00:00:00 ps namespaceを作成する前は、プロセスがたくさんあります。 namespace作成にはunshareコマンドを使います。 namespaceを作成したあとは、プロセス空間が別になるので、bashのプロセスしかないです。

Only 参考︓コンテナ技術⼊⾨ https://employment.en-japan.com/engineerhub/entry/2019/02/05/103000 $ ROOTFS=$(mktemp -d) $ CID=$(sudo docker container create centos:centos7) $ sudo docker container export $CID | tar -x -C $ROOTFS $ ln -s /usr/local/bin/bash $ROOTFS/bin/bash $ sudo docker container rm $CID $ UUID=$(uuidgen) $ sudo cgcreate -t $(id -un):$(id -gn) -a $(id -un):$(id -gn) -g cpu,memory:$UUID $ cgset -r memory.limit_in_bytes=10000000 $UUID $ cgset -r cpu.cfs_period_us=1000000 $UUID $ cgset -r cpu.cfs_quota_us=300000 $UUID $ CMD="/bin/sh" $ cgexec -g cpu,memory:$UUID \ unshare -muinpfr /bin/sh -c " mount -t proc proc $ROOTFS/proc && touch $ROOTFS$(tty); mount --bind $(tty) $ROOTFS$(tty) && touch $ROOTFS/dev/pts/ptmx; mount --bind /dev/pts/ptmx $ROOTFS/dev/pts/ptmx && ln -sf /dev/pts/ptmx $ROOTFS/dev/ptmx && touch $ROOTFS/dev/null && mount --bind /dev/null $ROOTFS/dev/null && /bin/hostname $UUID && exec capsh --chroot=$ROOTFS --drop=cap_sys_chroot -- -c 'exec $CMD' " ファイルシステムやユーザー空間まで分けた実⽤的なCentOS7のnamespace(コンテナ)を作ります。

Only ホストOS namespace / 先のコマンドは、以下の2つのことを実施しています。 bin etc var log spool ・・・ / bin etc var log spool ・・・ CentOS7の動作に必要なファイルを取得 namespaceの作成

Only こんなにたくさんのコマンド打つのめんどくさい・・・

Only Dockerを使えば解決たった1⾏のコマンドで、先程のダラダラ⻑いコマンドと同じことが実現出来ます。 $ docker run -it centos:centos7 /bin/bash

Only namespaceの作成その他コンテナ作成に必要なもろもろのコマンドの簡略化コンテナを作成するの必要なOSのイメージを Docker Hubからダウンロードつまり Dockerで実現できることは主に以下の2つ

Only ところで Docker Hubってなに︖

Only %PDLFS)VCͱ͸ʁ %PDLFS)VC CentOS 6 / bin etc ・・・ 7 / bin etc ・・・ 8 / bin etc ・・・ Ubuntu 16.0 / bin etc ・・・ 18.0 / bin etc ・・・ 19.0 / bin etc ・・・ etc ・・・ bin etc ・・・ 8 / bin etc ・・・ CentOS ホストOS namespace $ docker run -it centos:centos8 /bin/bash ダウンロードしてくるイメージを指定イメージをダウンロード 1$

Only Dockefileを使うとコンテナをカスタマイズできます︕︕

Only Dockerfile FROM centos:centos7 RUN yum –y install httpd CentOS7のイメージにApacheをインストールしてみます。そのためのDockerfileは以下のとおりです。 CentOS7のイメージをダウンロード Apacheをインストール

Only %PDLFS)VC CentOS 6 / bin etc ・・・ 7 / bin etc ・・・ 8 / bin etc ・・・ etc ・・・bin etc ・・・ 7 / bin etc ・・・ CentOS ホストOS namespace $ docker build -t web. イメージをダウンロード Dockerfileを作成し、以下のコマンドを実⾏すると、CentOS7のイメージ上にApacheがインストールされたコンテナが作成されます。 1$ var httpd Apacheのインストール

Only etc ・・・bin etc ・・・ 7 / bin etc ・・・ CentOS ホストOS namespace $ docker push XXX.azurecr.io/web:1.0 さらに作成したコンテナをもとにプライベートリポジトリにオリジナルイメージとしてプッシュ出来ます。 1$ var httpd ϓϥΠϕʔτ ϦϙδτϦ web etc ・・・bin etc ・・・ 1.0 / bin etc ・・・ var httpd

Only さらにプライベートリポジトリにプッシュしたイメージを他の開発者に配ることも出来ます。 ϓϥΠϕʔτ ϦϙδτϦ web etc ・・・bin etc ・・・ 1.0 / bin etc ・・・ var httpd ։ൃऀ" ։ൃऀ# ։ൃऀ$

Only Dockerfile FROM centos:centos7 ENV idp_version=3.4.6 # Inatall the libraries neccesary for building Shibboleth IdP RUN yum -y update && \ yum -y install wget java-1.8.0-openjdk # Download Shibboleth IdP RUN wget -q https://shibboleth.net/downloads/identity-provider/$idp_version/shibboleth-identity- provider-$idp_version.tar.gz && \ tar -zxvf shibboleth-identity-provider-$idp_version.tar.gz -C /opt && \ ln -s /opt/shibboleth-identity-provider-$idp_version/ /opt/shibboleth-idp COPY bin/ /usr/local/bin/ RUN chmod 750 /usr/local/bin/init-idp.sh もっと複雑な環境を構築するためにDockerfileです。

© SIOS Technology, Inc. All rights Reserved. 仮想化との違い 32 Internal
Only 開発環境の構築を例に仮想化との違いを考えてみます。

Only Ծ૝Խͷ৔߹ package jp.sios.funcB User.java 開発環境システム管理者システム構成が変更になったので、開発エンジニアの⽅は、この⼿順書に従って、環境を変更して下さーい。

Only Ծ૝Խͷ৔߹ 開発環境あれ、開発環境がうまく動かない・・・。あっ、⼿順書通りに実施していなかった・・・。システム管理者

Only ίϯςφͷ৔߹ 開発環境 Dockerイメージダウンロード ϓϥΠϕʔτ ϦϙδτϦ Dockerイメージからコンテナを⽣成システム管理者システム構成が変更になったDockerイメージをレポジトリからにプッシュ

Only コンテナを⽤いると開発環境の構築において以下のようなメリットがあります。開発者のPCにDockerさえインストールされていれば、イメージをダウンロードするだけで環境ができあがるので、ミスがないコンテナはカーネルを含まず軽量なのでダウンロードが速い。よって可搬性がよい。

Only 開発環境だけでなく本番環境にもコンテナを持っていたら便利だと思いませんか︖

Only 開発環境 Dockerイメージダウンロード ϓϥΠϕʔτ ϦϙδτϦ 修正したDockerイメージをプッシュシステム管理者システム構成が変更になったDockerイメージをレポジトリからにプッシュ本番環境 Dockerイメージから本番環境のコンテナを⽣成 ᶃ ᶄ ᶅ ᶆ

Only 開発環境 ϓϥΠϕʔτ ϦϙδτϦ ①〜④はOSまで含む環境なので、開発環境でも本番環境でも、その動作に違いはない。システム管理者本番環境 ᶃ ᶄ ᶅ ᶆ

Only つまり、本番環境にコンテナを⽤いると、以下のようなメリットがあります。本番環境も検証環境も、OSまで含めた同じイメージを使うので、全く同じように動作する。仮想化でありがちな、本番環境と検証環境の動作の差異がない。コンテナはホストOSのカーネルを共有し、OSのイメージのみのため、サイズが⼩さく、可搬性がよい。リポジトリからのダウンロードもすぐに終わる。

Only でも、本番環境ではいろんなことを考慮しなければなりません。

Only 例えば、、、負荷分散無停⽌更新監視ネットワーク管理(ルーティングなど) 他にもたくさん、、、、

Only それ、全部 Kubernetes が解決します︕︕

Only 開発環境 ϓϥΠϕʔτ ϦϙδτϦ ここをKubernetesにします。システム管理者 Kubernetes ᶃ ᶄ ᶅ ᶆ

© SIOS Technology, Inc. All rights Reserved. Kubernetesとは︖ 46 Internal
Only Kubernetesの基本原則は以下のとおりです。 Immutable Infrastructure 宣⾔的設定変更を積み重ねず全て作り直す。例えば何か⼀箇所でも変更があった場合は、その箇所だけ修正するのではなく、全て作り直す。設定ファイルによって⼀旦構築したら、何が起こってもその状態を維持する⾃⼰修復障害が発⽣しても⾃分で勝⼿に修復する。

Only Kubernetesとは、本番環境でコンテナを動かすための様々な機能を提供するOSSです。オートスケールスケジューリングセルフヒーリングロードバランシングローリングアップデート Infrastructure as Code

Only Kubernetesの基本的な構成は以下のとおりです。 Pod コンテナコンテナ Pod コンテナコンテナ Master Node Node ・・・・・・

Only Master Node 各Nodeの状態を管理するサーバー。例えば、各Node やPodの状態を常に監視し、どこにPodを配置したらよいかなどを管理する。 Podが配置されるサーバー。 Pod コンテナを論理的にまとめた単位。基本的には1Pod1 コンテナであることが多い。

Only *OGSBTUSVDUVSFBT$PEF Kubernetesでは、すべての構成をyaml形式のファイルで⽣成します。 apiVersion: apps/v1beta1 kind: Deployment metadata: name: techlab-admin spec: replicas: 2 selector: matchLabels: app: techlab-admin strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 0 template: metadata: labels: app: techlab-admin spec: containers: - name: wordpress image: XXXXXX.azurecr.io/techblog/wordpress:php7.4 ・・・

Only ϩʔυόϥϯγϯά httpd httpd httpd httpd httpd httpd httpd httpd httpd Node1 Node2 Node3 httpd …コンテナロードバランサー

Only Φʔτεέʔϧ httpd httpd httpd httpd httpd httpd httpd httpd httpd Node1 Node2 Node3 httpd …コンテナ httpd httpd httpd httpd httpd httpd httpd httpd httpd httpd httpd httpd httpd httpd httpd httpd httpd httpd リクエスト数や負荷に応じてコンテナを増減

Only εέδϡʔϦϯά httpd httpd httpd httpd httpd httpd httpd httpd httpd Node1(HDD) httpd …コンテナ DB DB DB DBなどディスクIOが多いコンテナを⾼速なディスク(SSD)のあるノードに配置する。 Node2(HDD) Node1(SSD)

Only ηϧϑώʔϦϯά httpd httpd httpd httpd httpd httpd Node1(HDD) httpd …コンテナ Nodeに障害などが発⽣してコンテナ(プロセス)が停⽌した場合、コンテナを再起動したり別のNodeに移したりして、処理を継続する。 Node2(HDD) Node1(SSD) java java java java java java

Only ϩʔϦϯάΞοϓσʔτ httpd httpd httpd httpd httpd httpd Node1(HDD) httpd …コンテナ Node2(HDD) Node1(SSD) httpd httpd httpd httpd httpd httpd 旧新旧旧新新旧コンテナへのユーザーからのアクセスを遮断 ᶃ 旧コンテナを停⽌ ᶄ 新コンテナを起動 ᶅ 新コンテナへのユーザーからのアクセスを開始 ᶆ

Only ϩʔϦϯάΞοϓσʔτͷ಺෦తͳॲཧ terminationGracePeriodSeconds (40秒) preStop sleep 3 apachectl –k graceful-stop sleep 30 SIGTERM SIGKILL サービス除外ユーザーの接続ユーザーの接続

Only Kubernetesのアーキテクチャは以下のとおりです。 Pod コンテナコンテナ kube-proxy kubelet API Server Scheduler Pod コンテナコンテナ kube-proxy kubelet Master Node Node ・・・・・・ etcd コマンド群 kubectl apply kubectl delete kubectl …

Only API Server Restのインタフェースを持つプロセスで、Kubernetes のリソース情報(Podに関する情報やCluster IPなど)を管理します。kube-proxyやkubeletなどの全てのプロセスは、このAPI Serverを介して、お互いの情報をやり取りします。 etcd kubernetesの情報を保存する⾼信頼分散KVSです。 API Serverは、Kubernetes稼働に必要な情報全てを etcdに情報を保存します。他にもflannel(Pod間の通信を実現するVXLAN管理サービス)も利⽤します。 kubelet Podの⽣成や停⽌を⾏います。定期的にAPI Serverに問い合わせて、⽣成や停⽌の数やタイミングを決めています。

Only scheduler 各Nodeの空き状況や状態を監視して、その結果をAPI Serverを通じて、kubeletに伝える役割を持っています。この情報を参考にして、kubeletはコンテナを⽣成します。例えば、後述しますが、ReplicaSetで複数台スケールするクラスタを作成したときは、このScheduler が開いているNodeにコンテナを作成するようkubelet に指⽰します。そして、コンテナは複数のNodeに配置されます。 kube-proxy Cluster IPの管理を⾏います。Cluster IPとは、サービスにアクセスするための代表的なIPアドレスになります。 Load BalancerなどのVIPに近いイメージです。このIP アドレスにアクセスすると、そのリクエストは複数の Podに分散されます。kube-proxyのお仕事は、定期的にAPI Server経由でKubernetesのリソース情報にアクセスし、必要に応じてiptableseのルールを作成し、 iptablesの機能によって負荷分散を⾏います。

Only kubectl kubectlなどのコマンド群です。ユーザーのインターフェースになります。このコマンドを使って、クラスタを作成したり削除したりとか、Kubernetesにおける全ての管理をします。実際はAPI Serverにリクエストを投げています。

Only API Server kubelet kube-proxy scheduler kubectl etcd 何か変更ないですか︖変更あればコンテナ構成を更新しますよ。何か変更ないですか︖変更あればネットワーク構成を更新しますよ。何か変更ないですか︖変更あればコンテナの配置変更しますよ。構成変更したいので、宜しくお願いします︕︕ etcdさん、変更情報記録してください︕︕

Only ネットワーク構成ってどうなってますか︖

Only Kubernetesのネットワーク構成は以下のとおりです︕︕ eth0 eth0 10.4.4.5 172.30.31.2 docker0 172.30.31.1 flannel.1 Cluster IP 10.254.236.167/32 eth0 eth0 172.30.91.1 docker0 172.30.91.1 flannel.1 172.30.31.0 10.4.4.7 172.30.91.0 node01 node02 Pod Pod httpd httpd Cluster IP 10.254.236.167/32

Only 先にご紹介したKubernetesのネットワーク図の解説です。 Pod間のネットワークはflannelというVXLANを管理するソフトウェアにより、172.30.0.0/16というネットワーク空間を持ち、さらにそのネットワークをPodごとに24ビットのネットワーク空間に区切っている。 flannel.1というデバイスがVXLANデバイスである。別ノード宛のパケットは、VXLANデバイスflannel.1によりVXLANヘッダが付与された形でカプセル化され、nodeのeth0を通り、別ノードに届く。

Only 先にご紹介したKubernetesのネットワーク図の解説です。 doker0という仮想ブリッジ(IPアドレスをもっている)があり、Podはこのブリッジにつながっている。 Cluster IPというIPアドレスがある。ネットワークインターフェースは持たず、iptablesの中で定義された仮想的なIPアドレスである。このIP アドレス宛のパケットは各nodeにロードバランスされる。

Only Kubernetes・・・構築するもの多すぎ・・・運⽤・管理も⼤変・・・ masterサーバー Nodeが必要な分だけ API Server kubelet scheduler ストレージ Dockerレジストリネットワーク

Only すべてマネージドにおまかせしましょう︕︕ masterサーバー Nodeが必要な分だけ API Server kubelet scheduler ストレージ Dockerレジストリネットワーク

Only そこで Azure Kubernetes Service の出番です︕︕

70 Internal Only Azure Kubernetes Serviceの特徴は以下のとおりです。 Masterサーバー、Nodeサーバーを構築する必要なし。管理も全ておまかせ。 Kubernetes⾃⾝のバージョンアップもGUIで⼀発あとからNodeの追加も可能

71 Internal Only GUIでらくらく環境構築︕︕

72 Internal Only Kubernetesで実は⼀番⼤変なロギングもすでにサービスが⽤意されている。

73 Internal Only もし、負荷が増⼤しNodeの追加が必要になったときでも、簡単に増減が可能。

74 Internal Only 進化が速いKubernetesのバージョンアップもGUIで⼀発︕︕

75 Internal Only Azure Kubernetes Serviceって何で出来てるの︖

76 Internal Only AKSクラスター Masterの機能 API Server Scheduler etcd Nodeの機能 Azure Load Balancer ・・・ Virtual Macihne (Virtual Machine Scale Sets) Virtual Netowork Azure Container Registry Public IP Address Log Analytics Azure DNS

導⼊のポイント 77

導⼊のポイント 78 Internal Only Kubernetesは銀の弾丸ではありません。

導⼊のポイント 79 Internal Only Kubernetesは複雑なシステムで設計が⼤変です。 Kubernetesが適さいないサービスに導⼊をすると、運⽤管理の⼿間ばかり増えて不幸になります・・・。

導⼊のポイント 80 Internal Only Kubernetes導⼊可否判断のポイントは、以下の3つです。その1︓頻繁な機能変更・追加があるかどうか︖ その2︓⼤量のリソースを消費するかどうか︖ その3︓急激なスケールアウトが必要かどうか︖

導⼊のポイント 81 Internal Only ͦͷɿසൟͳػೳมߋɾ௥Ճ͕͋Δ͔Ͳ͏͔ʁ 頻繁な機能変更・追加がある場合は、Kubernetes向きのシステムです。 Kubernetesにはローリングアップデート、ブルーグリーンデプロイ、カナリーデプロイ等、ユーザー影響なくデプロイできる機能が揃っている。 1機能1コンテナ単位で開発を⾏う「マイクロサービスアーキテクチャ」を⽤いると、Kubernetesはコンテナ単位で管理ができるので、運⽤が楽になる。例えば冒頭にご紹介した「スケジューリング」を⽤いてIOの必要な機能は、SSDがあるノードに配置するなど。

導⼊のポイント 82 Internal Only ͦͷɿେྔͷϦιʔεΛফඅ͢Δ͔Ͳ͏͔ʁ ⼤量のリソースを消費するサービスの場合、Kubernetesには向きません。 Kubernetesは、kube-proxyやkubelet等、Node上で様々なサービスが稼働するためオーバーヘッドが⾼く、⼤量にメモリやCPUを消費するサービスを載せられません。このような場合は、VirtualMachineのほうが、Kubernetesのようなオーバーヘッドもないのでパフォーマンスを発揮できます。

導⼊のポイント 83 Internal Only ͦͷɿٸܹͳεέʔϧΞ΢τ͕ඞཁ͔Ͳ͏͔ʁ 急激なスケールアウトが必要なサービスの場合は、Kubernetes向きのシステムです。 Kubernetesは、コンテナという単位で稼働するため、サービスの起動が⾼速で、スケールアップが得意です。簡単にスケールアウトしやすいサービスの場合、Kubernetes向きであると⾔えます。逆に、スケールアップすることでしかパフォーマンス向上を図れない場合、VirtualMachineやAppServiceのほうが向いています。

© SIOS Technology, Inc. All rights Reserved. よく頂くご質問 85 Internal
Only Kubernetesを本番で使う予定ないんだけど、、、それでもKubernetesを学ぶ価値は⼗分にあります。Kubernetesには、今後のシステム設計に必要なエッセンスがたくさん詰まっています。マイクロサービス、ブルーグリーンデプロイ、カナリーリリース、ステートレスな設計などです。Kubernetesを学ぶことによって得た知識は、必ず他のシステムでも役に⽴ちます︕︕

© SIOS Technology, Inc. All rights Reserved. よく頂くご質問 86 Internal
Only Kubernetesってむずかしいですか︖ Kubernetesはたくさんのコンポーネントが複雑に絡み合い、そしてアプリケーションとインフラの両⽅の知識が必要になるので、難しいと思われがちですが、そうではありません。コンピューター理論の基本(TCP/IPや HTTPのプロトコル)さえ抑えておけば⼤丈夫です。Kubernetesは最新の技術ですが、ベースとなっているのは実にレガシーな技術の塊です。

Only

Only 詳細は、弊社技術ブログをご参照ください。 https://tech-lab.sios.jp/archives/18794 Azure Kubernetes Serviceで実現する超低予算＆(ほぼ)フルマネージド＆本格的なWordPress環境

Only Azure Kubernetes Serviceで実現する超低予算＆(ほぼ)フルマネージド＆本格的な WordPress環境 https://tech-lab.sios.jp/archives/18794 ؔ࿈ϒϩά Azure Kubernetes Serviceで最速k8s https://tech-lab.sios.jp/archives/18536 実際の開発フローにおけるKubernetesの使い⽅ https://tech-lab.sios.jp/archives/7745 Kubernetesのネットワーク構成 https://tech-lab.sios.jp/archives/7857 【連載】世界⼀わかりみが深いコンテナ & Docker⼊⾨ https://tech-lab.sios.jp/archives/18811

Only 先々⽉発売のSoftware Designの VS Code + Docker関連の話題を執筆しました。

ご清聴ありがとうございました

コンテナ若葉マーク勉強会資料.pdf

コンテナ若葉マーク勉強会資料.pdf

More Decks by Noriyuki TAKEI

Featured

Transcript