前書き

containersを使用し始めている場合、ビルド、テスト、および展開を自動化する方法を知りたいと思うでしょう。 。 これらのプロセスにhttps://github.com/cncf/toc/blob/master/DEFINITION.md[Cloud Native]アプローチを採用することで、適切なインフラストラクチャAPIを活用して、アプリケーションを自動化してパッケージ化およびデプロイできます。

自動化を行うための2つのビルディングブロックには、_containerイメージとコンテナーオーケストレーターが含まれます。 昨年ほど、https://kubernetes.io/ [Kubernetes]がコンテナオーケストレーションのデフォルトの選択肢になりました。 * CI / CD with Kubernetes *シリーズの最初の記事では、次のことを行います。

  • Docker、https://github.com/projectatomic/buildah[Buildah]、およびhttps://github.com/GoogleContainerTools/kaniko[Kaniko]を使用してコンテナイメージを構築します。

  • TerraformでKubernetesクラスターを設定し、_Deployments_および_Services_を作成します。

  • _Custom Resources_を使用してKubernetesクラスターの機能を拡張します。

このチュートリアルの終わりまでに、Docker、Buildah、およびKanikoで構築されたコンテナーイメージと、展開、サービス、およびカスタムリソースを含むKubernetesクラスターが作成されます。

シリーズの今後の記事では、Kubernetesのパッケージ管理、https://jenkins-x.io/ [Jenkins X]やhttps://www.spinnaker.io/[Spin​​naker]などのCI / CDツール、関連するトピックを取り上げます。メッシュ、およびGitOps。

前提条件

  • 非rootユーザーアカウントを持つUbuntu 16.04サーバー。 ガイダンスについては、https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-16-04 [Ubuntu 16.04での初期サーバー設定]チュートリアルに従ってください。

  • Dockerはサーバーにインストールされています。 Ubuntu 16.04でDockerをインストールして使用する方法インストール手順。

  • https://hub.docker.com [Docker Hubアカウント]。 Docker Hubの使用開始の概要については、https://docs.docker.com/docker-hub/ [これらの手順]を参照してください。

  • DigitalOceanアカウントと個人アクセストークン。 https://www.digitalocean.com/docs/api/create-personal-access-token/ [これらの手順]を参照して、アクセストークンを取得してください。

  • コンテナとDockerに精通している。 詳細については、https://www.digitalocean.com/community/tutorials/webinar-series-getting-started-with-containers [ウェビナーシリーズ:コンテナ入門]を参照してください。

  • Kubernetesの概念に精通している。 詳細については、https://www.digitalocean.com/community/tutorials/an-introduction-to-kubernetes [Kubernetesの概要]を参照してください。

ステップ1-DockerおよびBuildahを使用したコンテナーイメージの構築

コンテナイメージは、コンテナの作成と実行に使用できる独自のアプリケーションコード、ランタイム、および依存関係を備えた自己完結型のエンティティです。 さまざまなツールを使用してコンテナーイメージを作成できます。この手順では、DockerとBuildahの2つでコンテナーを構築します。

Dockerfilesを使用したコンテナイメージの構築

Dockerは、Dockerfileから指示を読み取ることにより、コンテナーイメージを自動的に構築します。Dockerfileは、コンテナーイメージのアセンブルに必要なコマンドを含むテキストファイルです。 `+ docker image build +`コマンドを使用して、Dockerfileで提供されるコマンドラインの指示を実行する自動ビルドを作成できます。 イメージをビルドするときは、Dockerfileで_build context_を渡します。これには、環境を作成し、コンテナーイメージでアプリケーションを実行するために必要なファイルのセットが含まれます。

通常、Dockerfileとビルドコンテキスト用のプロジェクトフォルダーを作成します。 開始する `++`というフォルダーを作成します。

mkdir
cd

次に、 `+ demo +`フォルダー内にDockerfileを作成します。

nano Dockerfile

次のコンテンツをファイルに追加します。

〜/ demo / Dockerfile

FROM ubuntu:16.04

LABEL MAINTAINER [email protected]

RUN apt-get update \
   && apt-get install -y nginx \
   && apt-get clean \
   && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/* \
   && echo "daemon off;" >> /etc/nginx/nginx.conf

EXPOSE 80
CMD ["nginx"]

このDockerfileは、Nginxを実行するイメージを構築する一連の命令で構成されています。 ビルドプロセス中、 + ubuntu:16.04 +`はベースイメージとして機能し、 `+ nginx +`パッケージがインストールされます。 `+ CMD`命令を使用して、コンテナの起動時に + nginx`がデフォルトのコマンドになるように設定しました。

次に、ビルドコンテキストとして現在のディレクトリ(。)を使用して、 `+ docker image build`コマンドでコンテナイメージをビルドします。 このコマンドに「+ -t 」オプションを渡すと、画像に「+」という名前が付けられます。

sudo docker image build -t  .

次の出力が表示されます。

OutputSending build context to Docker daemon  49.25MB
Step 1/5 : FROM ubuntu:16.04
---> 7aa3602ab41e
Step 2/5 : MAINTAINER [email protected]
---> Using cache
---> 552b90c2ff8d
Step 3/5 : RUN apt-get update     && apt-get install -y nginx     && apt-get clean     && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*     && echo "daemon off;" >> /etc/nginx/nginx.conf
---> Using cache
---> 6bea966278d8
Step 4/5 : EXPOSE 80
---> Using cache
---> 8f1c4281309e
Step 5/5 : CMD ["nginx"]
---> Using cache
---> f545da818f47
Successfully built f545da818f47
Successfully tagged nginx:latest

これで画像が作成されました。 次のコマンドを使用して、Dockerイメージを一覧表示できます。

docker image ls
OutputREPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
nkhare/nginx        latest              4073540cbcec        3 seconds ago       171MB
ubuntu              16.04               7aa3602ab41e        11 days ago

`+ nkhare / nginx:latest +`イメージを使用してコンテナを作成できるようになりました。

Project Atomic-Buildahを使用したコンテナイメージの構築

Buildahは、_Open Container Initiative(https://www.opencontainers.org [OCI])_準拠のイメージを迅速に構築するためのhttps://github.com/projectatomic/[Project Atomic]によって開発されたCLIツールです。 OCIは、業界のベストプラクティスを標準化するために、コンテナランタイムとイメージの仕様を提供します。

Buildahは、作業コンテナーまたはDockerfileからイメージを作成できます。 Dockerデーモンを使用せずにユーザー空間でイメージを完全に構築でき、「+ build 」、「 list 」、「 push 」、「 tag +」などのイメージ操作を実行できます。 この手順では、ソースからBuildahをコンパイルし、それを使用してコンテナーイメージを作成します。

Buildahをインストールするには、パッケージやパッケージセキュリティなどを管理できるツールなど、必要な依存関係が必要になります。 次のコマンドを実行して、これらのパッケージをインストールします。

cd
sudo apt-get install software-properties-common
sudo add-apt-repository ppa:alexlarsson/flatpak
sudo add-apt-repository ppa:gophers/archive
sudo apt-add-repository ppa:projectatomic/ppa
sudo apt-get update
sudo apt-get install bats btrfs-tools git libapparmor-dev libdevmapper-dev libglib2.0-dev libgpgme11-dev libostree-dev libseccomp-dev libselinux1-dev skopeo-containers go-md2man

`+ buildah +`ソースコードをコンパイルしてパッケージを作成するため、https://golang.org/ [Go]をインストールする必要もあります。

sudo apt-get update
sudo curl -O https://storage.googleapis.com/golang/go1.8.linux-amd64.tar.gz
sudo tar -xvf go1.8.linux-amd64.tar.gz
sudo mv go /usr/local
sudo echo 'export PATH=$PATH:/usr/local/go/bin' >> ~/.profile
source ~/.profile
go version

次の出力が表示され、インストールが成功したことが示されます。

Outputgo version go linux/amd64

これで、 `+ runah `バイナリとともに、パッケージを作成するための ` buildah `ソースコードを取得できます。 ` runc `は、 ` OCI +`コンテナランタイムの実装であり、Buildahコンテナの実行に使用します。

次のコマンドを実行して、 `+ runc `および ` buildah +`をインストールします。

mkdir ~/buildah
cd ~/buildah
export GOPATH=`pwd`
git clone https://github.com/containers/buildah ./src/github.com/containers/buildah
cd ./src/github.com/containers/buildah
make runc all TAGS="apparmor seccomp"
sudo cp ~/buildah/src/github.com/opencontainers/runc/runc /usr/bin/.
sudo apt install buildah

次に、 `+ / etc / containers / registries.conf +`ファイルを作成して、コンテナレジストリを設定します。

sudo nano /etc/containers/registries.conf

次のコンテンツをファイルに追加して、レジストリを指定します。

/etc/containers/registries.conf

# This is a system-wide configuration file used to
# keep track of registries for various container backends.
# It adheres to TOML format and does not support recursive
# lists of registries.

# The default location for this configuration file is /etc/containers/registries.conf.

# The only valid categories are: 'registries.search', 'registries.insecure',
# and 'registries.block'.

[registries.search]
registries = ['docker.io', 'registry.fedoraproject.org', 'quay.io', 'registry.access.redhat.com', 'registry.centos.org']

# If you need to access insecure registries, add the registry's fully-qualified name.
# An insecure registry is one that does not have a valid SSL certificate or only does HTTP.
[registries.insecure]
registries = []

# If you need to block pull access from a registry, uncomment the section below
# and add the registries fully-qualified name.
#
# Docker only
[registries.block]
registries = []

`+ registries.conf +`設定ファイルは、レジストリまたはドメイン部分を含まないイメージ名を完成させるときにどのレジストリを参照するかを指定します。

次に、ビルドコンテキストとして `+ https:// github.com / do-community / rsvpapp-webinar1 +`リポジトリを使用して、次のコマンドを実行してイメージをビルドします。 このリポジトリには、関連するDockerfileも含まれています。

sudo buildah build-using-dockerfile -t rsvpapp:buildah github.com/do-community/rsvpapp-webinar1

このコマンドは、 `+ https:// github.com / do-community / rsvpapp-webinar1 `リポジトリで利用可能なDockerfilleから ` rsvpapp:buildah +`という名前のイメージを作成します。

イメージをリストするには、次のコマンドを使用します。

sudo buildah images

次の出力が表示されます。

OutputIMAGE ID             IMAGE NAME                                               CREATED AT             SIZE
b0c552b8cf64         docker.io/teamcloudyuga/python:alpine                    Sep 30, 2016 04:39     95.3 MB

これらのイメージの1つは、作成したばかりの `+ localhost / rsvpapp:buildah `です。 もう1つの ` docker.io / teamcloudyuga / python:alpine +`は、Dockerfileのベースイメージです。

イメージを作成したら、Docker Hubにプッシュできます。 これにより、将来使用するために保存できます。 まず、コマンドラインからDocker Hubアカウントにログインする必要があります。

docker login -u  -p

ログインが成功すると、Docker Hubの資格情報を含むファイル「〜/ .docker / config.json」が取得されます。 その後、そのファイルを ` buildah +`で使用して、イメージをDocker Hubにプッシュできます。

たとえば、作成したばかりのイメージをプッシュする場合は、 `+ authfile +`とプッシュするイメージを引用して次のコマンドを実行できます。

sudo buildah push --authfile ~/.docker/config.json rsvpapp:buildah docker:///rsvpapp:buildah

次のコマンドを使用して、結果のイメージをローカルDockerデーモンにプッシュすることもできます。

sudo buildah push rsvpapp:buildah docker-daemon:rsvpapp:buildah

最後に、作成したDockerイメージを見てください。

sudo docker image ls
OutputREPOSITORY          TAG                 IMAGE ID            CREATED             SIZE

nkhare/nginx        latest              01f0982d91b8        17 minutes ago      172MB
ubuntu              16.04               b9e15a5d1e1a        5 days ago          115MB

予想どおり、 `+ buildah `を使用してエクスポートされた新しいイメージ ` rsvpapp:buildah +`が表示されます。

DockerとBuildahの2つの異なるツールを使用してコンテナーイメージを構築した経験があります。 次に、Kubernetesでコンテナのクラスターをセットアップする方法について説明します。

手順2-kubeadmとTerraformを使用してDigitalOceanでKubernetesクラスターを設定する

DigitalOceanでKubernetesを設定するには、さまざまな方法があります。 たとえば、https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm/ [kubeadm]でKubernetesを設定する方法の詳細については、https://www.digitalocean.comをご覧ください。 / community / tutorials / how-to-create-a-kubernetes-1-11-cluster-using-kubeadm-on-ubuntu-18-04 [Ubuntu 18.04でKubeadmを使用してKubernetesクラスターを作成する方法]。

このチュートリアルシリーズでは、アプリケーション開発へのクラウドネイティブアプローチの採用について説明しているため、クラスターのセットアップ時にこの方法論を適用します。 具体的には、kubeadmとhttps://www.terraform.io/[Terraform]を使用してクラスターの作成を自動化します。これは、インフラストラクチャの作成と変更を簡素化するツールです。

個人用アクセストークンを使用して、TerraformでDigitalOceanに接続し、3つのサーバーをプロビジョニングします。 これらのVM内で `+ kubeadm +`コマンドを実行して、1つのマスターノードと2つのワーカーを含む3ノードKubernetesクラスターを作成します。

Ubuntuサーバーで、https://www.digitalocean.com/community/tutorials/how-to-configure-ssh-key-based-authentication-on-a-linux-server [SSHキー]のペアを作成します。 VMへのパスワードなしのログインを許可します。

ssh-keygen -t rsa

次の出力が表示されます。

OutputGenerating public/private rsa key pair.
Enter file in which to save the key (~/.ssh/id_rsa):

+ ENTER`を押してキーペアをホームディレクトリの +〜/ .ssh`ディレクトリに保存するか、別の宛先を入力します。

次に、次のプロンプトが表示されます。

OutputEnter passphrase (empty for no passphrase):

この場合、パスワードなしで「+ ENTER +」を押して、ノードへのパスワードなしのログインを有効にします。

キーペアが作成されたことを確認するメッセージが表示されます。

OutputYour identification has been saved in ~/.ssh/id_rsa.
Your public key has been saved in ~/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:lCVaexVBIwHo++NlIxccMW5b6QAJa+ZEr9ogAElUFyY [email protected]
The key's randomart image is:
+---[RSA 2048]----+
|++.E ++o=o*o*o   |
|o   +..=.B = o   |
|.    .* = * o    |
| .   =.o + *     |
|  . . o.S + .    |
|   . +.    .     |
|    . ... =      |
|        o= .     |
|       ...       |
+----[SHA256]-----+

次のコマンドを実行して公開鍵を取得します。これにより、端末に表示されます。

cat ~/.ssh/id_rsa.pub

https://www.digitalocean.com/docs/droplets/how-to/add-ssh-keys/to-account/ [これらの指示]に従って、このキーをDigitalOceanアカウントに追加します。

次に、Terraformをインストールします。

sudo apt-get update
sudo apt-get install unzip
wget https://releases.hashicorp.com/terraform/0.11.7/terraform_0.11.7_linux_amd64.zip
unzip terraform_0.11.7_linux_amd64.zip
sudo mv terraform /usr/bin/.
terraform version

Terraformのインストールを確認する出力が表示されます。

OutputTerraform v

次に、次のコマンドを実行して、Kubernetesクラスタと通信するCLIツールである `+ kubectl `をインストールし、ユーザーのホームディレクトリに `〜/ .kube +`ディレクトリを作成します。

sudo apt-get install apt-transport-https
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
sudo touch /etc/apt/sources.list.d/kubernetes.list
echo "deb http://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee -a /etc/apt/sources.list.d/kubernetes.list
sudo apt-get update
sudo apt-get install kubectl
mkdir -p ~/.kube

+〜/ .kube +`ディレクトリを作成すると、設定ファイルをこの場所にコピーできます。 このセクションの後半でKubernetesセットアップスクリプトを実行したら、これを行います。 デフォルトでは、 `+ kubectl + CLIは `+〜/ .kube +`ディレクトリで設定ファイルを探してクラスターにアクセスします。

次に、このチュートリアルのサンプルプロジェクトリポジトリを複製します。これには、インフラストラクチャをセットアップするためのTerraformスクリプトが含まれています。

git clone https://github.com/do-community/k8s-cicd-webinars.git

Terraformスクリプトディレクトリに移動します。

cd k8s-cicd-webinars/webinar1/2-kubernetes/1-Terraform/

SSH公開キーのフィンガープリントを取得します。

ssh-keygen -E md5 -lf ~/.ssh/id_rsa.pub | awk '{print $2}'

次のような出力が表示され、強調表示された部分がキーを表します。

OutputMD5:

キーはここに表示されているものとは異なることに注意してください。

Terraformが使用できるように、指紋を環境変数に保存します。

export FINGERPRINT=

次に、DOパーソナルアクセストークンをエクスポートします。

export TOKEN=

次に、 `+〜/ k8s-cicd-webinars / webinar1 / 2-kubernetes / 1-Terraform / +`プロジェクトディレクトリを見てください。

ls
Outputcluster.tf  destroy.sh  files outputs.tf  provider.tf  script.sh

このフォルダーには、TerraformでKubernetesクラスターをデプロイするために必要なスクリプトと構成ファイルが含まれています。

`+ script.sh +`スクリプトを実行して、Kubernetesクラスターのセットアップをトリガーします。

./script.sh

スクリプトの実行が完了すると、作成したKubernetesクラスターを使用するように「+ kubectl +」が設定されます。

`+ kubectl get nodes +`を使用してクラスターノードを一覧表示します。

kubectl get nodes
OutputNAME                STATUS    ROLES     AGE       VERSION
k8s-master-node     Ready     master    2m        v1.10.0
k8s-worker-node-1   Ready     <none>    1m        v1.10.0
k8s-worker-node-2   Ready     <none>    57s       v1.10.0

これで、1つのマスターノードと2つのワーカーノードが `+ Ready +`状態になりました。

Kubernetesクラスターをセットアップすると、コンテナーイメージを構築するための別のオプションhttps://github.com/GoogleContainerTools/kaniko[Kaniko from Google]を探索できるようになりました。

ステップ3-Kanikoを使用したコンテナイメージの構築

このチュートリアルの前半で、DockerfilesとBuildahを使用してコンテナーイメージを構築しました。 しかし、コンテナイメージをKubernetesで直接構築できるとしたらどうでしょうか。 Kubernetes内で `+ docker image build`コマンドを実行する方法がありますが、これはネイティブのKubernetesツールではありません。 イメージを構築するにはDockerデーモンに依存する必要があり、クラスター内のhttps://kubernetes.io/docs/concepts/workloads/pods/pod/[Pods]のいずれかで実行する必要があります。

Kanikoというツールを使用すると、既存のKubernetesクラスターでDockerfileを使用してコンテナーイメージを構築できます。 この手順では、Kanikoを使用してDockerfileでコンテナーイメージを構築します。 次に、この画像をDocker Hubにプッシュします。

画像をDocker Hubにプッシュするには、Docker Hubの資格情報をKanikoに渡す必要があります。 前のステップで、Docker Hubにログインし、ログイン認証情報で `+〜/ .docker / config.json`ファイルを作成しました。 この設定ファイルを使用してKubernetes _ConfigMap_オブジェクトを作成し、Kubernetesクラスター内に資格情報を保存しましょう。 ConfigMapオブジェクトは、構成パラメーターを保存し、アプリケーションから分離するために使用されます。

+〜/ .docker / config.json`ファイルを使用して + docker-config`というConfigMapを作成するには、次のコマンドを実行します。

sudo kubectl create configmap docker-config --from-file=$HOME/.docker/config.json

次に、 `〜/ k8s-cicd-webinars / webinar1 / 2-kubernetes / 1-Terraform / +`ディレクトリに ` pod-kaniko.yml +`というPod定義ファイルを作成できます(ただし、どこにでも移動できます) 。

まず、 `+〜/ k8s-cicd-webinars / webinar1 / 2-kubernetes / 1-Terraform / +`ディレクトリにいることを確認してください:

cd ~/k8s-cicd-webinars/webinar1/2-kubernetes/1-Terraform/

`+ pod-kaniko.yml +`ファイルを作成します:

nano pod-kaniko.yml

次のコンテンツをファイルに追加して、Podをデプロイするときに何が起こるかを指定します。 ポッドの「+ args 」フィールドの「+」を、独自のDocker Hubユーザー名に置き換えてください:

〜/ k8s-cicd-webinars / webinar1 / 2-kubernetes / 1-Terraform / pod-kaniko.yaml

apiVersion: v1
kind: Pod
metadata:
 name: kaniko
spec:
 containers:
 - name: kaniko
   image: gcr.io/kaniko-project/executor:latest
   args: ["--dockerfile=./Dockerfile",
           "--context=/tmp/rsvpapp/",
           "--destination=docker.io//rsvpapp:kaniko",
           "--force" ]
   volumeMounts:
     - name: docker-config
       mountPath: /root/.docker/
     - name: demo
       mountPath: /tmp/rsvpapp
 restartPolicy: Never
 initContainers:
   - image: python
     name: demo
     command: ["/bin/sh"]
     args: ["-c", "git clone https://github.com/do-community/rsvpapp-webinar1.git /tmp/rsvpapp"]
     volumeMounts:
     - name: demo
       mountPath: /tmp/rsvpapp
 restartPolicy: Never
 volumes:
   - name: docker-config
     configMap:
       name: docker-config
   - name: demo
     emptyDir: {}

この構成ファイルは、Podがデプロイされたときに何が起こるかを説明しています。 まず、https://kubernetes.io/docs/concepts/workloads/pods/init-containers/ [Init container]はDockerfileを使用してGitリポジトリのクローンを作成します。+ https://github.com/do-community/ rsvpapp-webinar1.git + `を、 + demo + `と呼ばれる共有ボリュームに入れます。 Initコンテナは、アプリケーションコンテナの前に実行され、アプリケーションコンテナからの実行が望ましくないユーティリティやその他のタスクの実行に使用できます。 次に、アプリケーションコンテナ `+ kaniko `がDockerfileを使用してイメージを構築し、ConfigMapボリューム ` docker-config +`に渡した資格情報を使用して、結果のイメージをDocker Hubにプッシュします。

`+ kaniko +`ポッドをデプロイするには、次のコマンドを実行します。

kubectl apply -f pod-kaniko.yml

次の確認が表示されます。

Outputpod/kaniko created

ポッドのリストを取得します。

kubectl get pods

次のリストが表示されます。

OutputNAME      READY     STATUS     RESTARTS   AGE
kaniko    0/1       Init:0/1   0          47s

数秒待ってから、ステータスの更新のために `+ kubectl get pods +`を再度実行します。

kubectl get pods

以下が表示されます。

OutputNAME      READY     STATUS    RESTARTS   AGE
kaniko    1/1       Running   0          1m

最後に、最終的なステータスの更新のために `+ kubectl get pods +`をもう一度実行します。

kubectl get pods
OutputNAME      READY     STATUS      RESTARTS   AGE
kaniko    0/1       Completed   0          2m

この一連の出力は、Initコンテナが実行され、GitHubリポジトリが `+ demo +`ボリューム内に複製されたことを示しています。 その後、Kanikoのビルドプロセスが実行され、最終的に終了しました。

ポッドのログを確認します。

kubectl logs kaniko

次の出力が表示されます。

Outputtime="2018-08-02T05:01:24Z" level=info msg="appending to multi args docker.io//rsvpapp:kaniko"
time="2018-08-02T05:01:24Z" level=info msg="Downloading base image nkhare/python:alpine"
.
.
.
ime="2018-08-02T05:01:46Z" level=info msg="Taking snapshot of full filesystem..."
time="2018-08-02T05:01:48Z" level=info msg="cmd: CMD"
time="2018-08-02T05:01:48Z" level=info msg="Replacing CMD in config with [/bin/sh -c python rsvp.py]"
time="2018-08-02T05:01:48Z" level=info msg="Taking snapshot of full filesystem..."
time="2018-08-02T05:01:49Z" level=info msg="No files were changed, appending empty layer to config."
2018/08/02 05:01:51 mounted blob: sha256:bc4d09b6c77b25d6d3891095ef3b0f87fbe90621bff2a333f9b7f242299e0cfd
2018/08/02 05:01:51 mounted blob: sha256:809f49334738c14d17682456fd3629207124c4fad3c28f04618cc154d22e845b
2018/08/02 05:01:51 mounted blob: sha256:c0cb142e43453ebb1f82b905aa472e6e66017efd43872135bc5372e4fac04031
2018/08/02 05:01:51 mounted blob: sha256:606abda6711f8f4b91bbb139f8f0da67866c33378a6dcac958b2ddc54f0befd2
2018/08/02 05:01:52 pushed blob sha256:16d1686835faa5f81d67c0e87eb76eab316e1e9cd85167b292b9fa9434ad56bf
2018/08/02 05:01:53 pushed blob sha256:358d117a9400cee075514a286575d7d6ed86d118621e8b446cbb39cc5a07303b
2018/08/02 05:01:55 pushed blob sha256:5d171e492a9b691a49820bebfc25b29e53f5972ff7f14637975de9b385145e04
2018/08/02 05:01:56 index.docker.io//rsvpapp:kaniko: digest: sha256:831b214cdb7f8231e55afbba40914402b6c915ef4a0a2b6cbfe9efb223522988 size: 1243

ログから、 `+ kaniko +`コンテナがDockerfileからイメージを構築し、それをDocker Hubアカウントにプッシュしたことがわかります。

これで、Dockerイメージをプルできます。 必ず++をDocker Hubユーザー名に置き換えてください:

docker pull /rsvpapp:kaniko

プルの確認が表示されます:

Outputkaniko: Pulling from /rsvpapp
c0cb142e4345: Pull complete
bc4d09b6c77b: Pull complete
606abda6711f: Pull complete
809f49334738: Pull complete
358d117a9400: Pull complete
5d171e492a9b: Pull complete
Digest: sha256:831b214cdb7f8231e55afbba40914402b6c915ef4a0a2b6cbfe9efb223522988
Status: Downloaded newer image for /rsvpapp:kaniko

これでKubernetesクラスターが正常に構築され、クラスター内から新しいイメージが作成されました。 _Deployments_および_Services_の説明に移りましょう。

手順4-Kubernetesの展開とサービスを作成する

Kubernetes _Deployments_を使用すると、アプリケーションを実行できます。 展開では、ポッドに必要な状態を指定して、ロールアウト全体の一貫性を確保します。 このステップでは、 +〜/ k8s-cicd-webinars / webinar1 / 2-kubernetes / 1-に + deployment.yml + `というhttps://www.nginx.com/[Nginx]デプロイメントファイルを作成します。 Nginx Deploymentを作成するTerraform / + `ディレクトリ。

まず、ファイルを開きます。

nano deployment.yml

次の構成をファイルに追加して、Nginx Deploymentを定義します。

〜/ k8s-cicd-webinars / webinar1 / 2-kubernetes / 1-Terraform / deployment.yml

apiVersion: apps/v1
kind: Deployment
metadata:
 name: nginx-deployment
 labels:
   app: nginx
spec:
 replicas: 3
 selector:
   matchLabels:
     app: nginx
 template:
   metadata:
     labels:
       app: nginx
   spec:
     containers:
     - name: nginx
       image: nginx:1.7.9
       ports:
       - containerPort: 80

このファイルは、それぞれがポート「80」で「+ nginx 」コンテナを実行する3つのポッドを作成する「 nginx-deployment +」という名前のデプロイメントを定義します。

展開を展開するには、次のコマンドを実行します。

kubectl apply -f deployment.yml

デプロイメントが作成されたことの確認が表示されます。

Outputdeployment.apps/nginx-deployment created

展開を一覧表示します。

kubectl get deployments
OutputNAME               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3         3         3            3           29s

+ nginx-deployment +`デプロイメントが作成され、ポッドの望ましい数と現在の数が同じであることがわかります: `+ 3 +

デプロイメントが作成したポッドをリストするには、次のコマンドを実行します。

kubectl get pods
OutputNAME                                READY     STATUS      RESTARTS   AGE
kaniko                              0/1       Completed   0          9m
nginx-deployment-75675f5897-nhwsp   1/1       Running     0          1m
nginx-deployment-75675f5897-pxpl9   1/1       Running     0          1m
nginx-deployment-75675f5897-xvf4f   1/1       Running     0          1m

この出力から、必要な数のPodが実行されていることがわかります。

アプリケーションの展開を内部および外部に公開するには、Service_というKubernetesオブジェクトを作成する必要があります。 各サービスは、_ServiceType_を指定します。これは、サービスの公開方法を定義します。 この例では、各ノードの静的ポートでサービスを公開する_NodePort ServiceTypeを使用します。

これを行うには、ファイル「+ service.yml 」を「〜/ k8s-cicd-webinars / webinar1 / 2-kubernetes / 1-Terrafrom / +」ディレクトリに作成します。

nano service.yml

次のコンテンツを追加して、サービスを定義します。

〜/ k8s-cicd-webinars / webinar1 / 2-kubernetes / 1-Terrafrom / service.yml

kind: Service
apiVersion: v1
metadata:
 name: nginx-service
spec:
 selector:
   app: nginx
 type: NodePort
 ports:
 - protocol: TCP
   port: 80
   targetPort: 80
   nodePort: 30111

これらの設定は、サービス「+ nginx-service 」を定義し、ポッドのポート「+80」をターゲットにすることを指定します。 `+ nodePort +`は、アプリケーションが外部トラフィックを受け入れるポートを定義します。

サービスをデプロイするには、次のコマンドを実行します。

kubectl apply -f service.yml

確認が表示されます:

Outputservice/nginx-service created

サービスのリスト:

kubectl get service

次のリストが表示されます。

OutputNAME            TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
kubernetes      ClusterIP   10.96.0.1       <none>        443/TCP        5h
nginx-service   NodePort    10.100.98.213   <none>        80:/TCP   7s

サービス「+ nginx-service」はポート「30111」で公開され、ノードのパブリックIPのいずれからでもアクセスできるようになりました。 たとえば、「+ http://:30111+」または「+ http://:30111+」に移動すると、Nginxの標準のウェルカムページが表示されます。

展開をテストしたら、展開とサービスの両方をクリーンアップできます。

kubectl delete deployment nginx-deployment
kubectl delete service nginx-service

これらのコマンドは、作成した展開とサービスを削除します。

展開とサービスを使用したので、カスタムリソースの作成に進みます。

ステップ5-Kubernetesでのカスタムリソースの作成

Kubernetesは、限定されていますが、すぐに使用できる機能と機能を提供します。 ただし、https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/ [カスタムリソース]機能を使用して、Kubernetesのサービスを拡張することは可能です。 Kubernetesでは、_resource_は、API _objects_のコレクションを格納するKubernetes APIのエンドポイントです。 Podリソースには、たとえばPodオブジェクトのコレクションが含まれます。 カスタムリソースを使用すると、ネットワークやストレージなどのカスタムサービスを追加できます。 これらの追加は、いつでも作成または削除できます。

カスタムオブジェクトの作成に加えて、コントロールプレーンでKubernetes Controller_コンポーネントのサブコントローラーを使用して、オブジェクトの現在の状態が目的の状態と等しくなるようにすることもできます。 Kubernetes Controllerには、指定されたオブジェクト用のサブコントローラーがあります。 たとえば、https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/ [_ReplicaSet]は、必要なポッドカウントの一貫性を維持するサブコントローラーです。 カスタムリソースとコントローラーを組み合わせると、リソースの目的の状態を指定できる真の宣言型APIを取得できます。

この手順では、カスタムリソースと関連オブジェクトを作成します。

カスタムリソースを作成するには、最初に `〜/ k8s-cicd-webinars / webinar1 / 2-kubernetes / 1-Terrafrom / +`ディレクトリに ` crd.yml +`というファイルを作成します:

nano crd.yml

次のカスタムリソース定義(CRD)を追加します。

〜/ k8s-cicd-webinars / webinar1 / 2-kubernetes / 1-Terrafrom / crd.yml

apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
 name: webinars.digitalocean.com
spec:
 group: digitalocean.com
 version: v1
 scope: Namespaced
 names:
   plural: webinars
   singular: webinar
   kind: Webinar
   shortNames:
   - wb

`+ crd.yml +`で定義されたCRDをデプロイするには、次のコマンドを実行します:

kubectl create -f crd.yml

リソースが作成されたことの確認が表示されます。

Outputcustomresourcedefinition.apiextensions.k8s.io/webinars.digitalocean.com created

+ crd.yml +`ファイルは、新しいRESTfulリソースパスを作成しました: `+ / apis / digtialocean.com / v1 / namespaces / * / webinars +。 これで、 + CustomResourceDefinition +`の `+ names +`セクションにリストしたように、 `+ webinars ++ webinar ++ Webinar +、および `+ wb +`を使用してオブジェクトを参照できます。 次のコマンドでRESTfulリソースを確認できます。

kubectl proxy & curl 127.0.0.1:8001/apis/digitalocean.com

次の出力が表示されます。

OutputHTTP/1.1 200 OK
Content-Length: 238
Content-Type: application/json
Date: Fri, 03 Aug 2018 06:10:12 GMT

{
   "apiVersion": "v1",
   "kind": "APIGroup",
   "name": "digitalocean.com",
   "preferredVersion": {
       "groupVersion": "digitalocean.com/v1",
       "version": "v1"
   },
   "serverAddressByClientCIDRs": null,
   "versions": [
       {
           "groupVersion": "digitalocean.com/v1",
           "version": "v1"
       }
   ]
}

次に、 `+ webinar.yml +`というファイルを開いて、新しいカスタムリソースを使用するためのオブジェクトを作成します。

nano webinar.yml

次のコンテンツを追加して、オブジェクトを作成します。

〜/ k8s-cicd-webinars / webinar1 / 2-kubernetes / 1-Terrafrom / webinar.yml

apiVersion: "digitalocean.com/v1"
kind: Webinar
metadata:
 name: webinar1
spec:
 name: webinar
 image: nginx

次のコマンドを実行して、これらの変更をクラスターにプッシュします。

kubectl apply -f webinar.yml

次の出力が表示されます。

Outputwebinar.digitalocean.com/webinar1 created

`+ kubectl `を使用して、 ` webinar +`オブジェクトを管理できるようになりました。 例えば:

kubectl get webinar
OutputNAME       CREATED AT
webinar1   21s

これで、 `+ webinar1 +`というオブジェクトが作成されました。 コントローラーがあった場合、オブジェクトの作成をインターセプトし、定義された操作を実行していました。

カスタムリソース定義の削除

カスタムリソースのすべてのオブジェクトを削除するには、次のコマンドを使用します。

kubectl delete webinar --all

あなたは見るでしょう:

Outputwebinar.digitalocean.com "webinar1" deleted

カスタムリソース自体を削除します。

kubectl delete crd webinars.digitalocean.com

削除されたという確認が表示されます。

Outputcustomresourcedefinition.apiextensions.k8s.io "webinars.digitalocean.com" deleted

削除後、以前に `+ curl +`コマンドでテストしたAPIエンドポイントにアクセスできなくなります。

このシーケンスは、Kubernetesコードを変更せずにKubernetesの機能を拡張する方法の概要です。

手順6-Kubernetesクラスターの削除

Kubernetesクラスター自体を破棄するには、 `〜/ k8s-cicd-webinars / webinar1 / 2-kubernetes / 1-Terrafrom +`フォルダーの ` destroy.sh +`スクリプトを使用できます。 このディレクトリにいることを確認してください。

cd ~/k8s-cicd-webinars/webinar1/2-kubernetes/1-Terrafrom

スクリプトを実行します。

./destroy.sh

このスクリプトを実行すると、TerraformがDigitalOcean APIと通信し、クラスター内のサーバーを削除できるようになります。

結論

このチュートリアルでは、さまざまなツールを使用してコンテナイメージを作成しました。 これらのイメージを使用すると、任意の環境でコンテナーを作成できます。 また、Terraformを使用してKubernetesクラスターをセットアップし、DeploymentおよびServiceオブジェクトを作成して、アプリケーションをデプロイおよび公開します。 さらに、カスタムリソースを定義してKubernetesの機能を拡張しました。

これで、KubernetesでCI / CD環境を構築するための強固な基盤ができました。これについては、今後の記事で説明します。