前回、MinikubeでKubernetesの環境が入った仮想マシンを、VirtualBoxに構築しました。
Kubernetesは、基本的にはkubectlコマンドで操作するらしいのですが、
⇧ 上記サイト様によりますと、
Kubernetesクラスタを操作する際には、CLIツールのkubectlとYAML形式で書かれたManifestファイルを用いてKubernetes Masterに「リソース」の登録を行います。実際にはkubectlも内部でKubernetes MasterのAPIを叩いているだけなので、ライブラリやcurlなどでも操作することが可能です。
Kubernetesは、YAML形式のファイル（拡張子が「.yml」）に設定した情報を元に、エンドポイントとなるAPIを起動させているということで、kubectlコマンドでなくても、利用はできるみたい...。
本家のサイトでも、
To work with Kubernetes, you use Kubernetes API objects to describe your cluster’s desired state: what applications or other workloads you want to run, what container images they use, the number of replicas, what network and disk resources you want to make available, and more. You set your desired state by creating objects using the Kubernetes API, typically via the command-line interface, kubectl. You can also use the Kubernetes API directly to interact with the cluster and set or modify your desired state.
Once you’ve set your desired state, the Kubernetes Control Plane works to make the cluster’s current state match the desired state. To do so, Kubernetes performs a variety of tasks automatically–such as starting or restarting containers, scaling the number of replicas of a given application, and more. The Kubernetes Control Plane consists of a collection of processes running on your cluster:
「Kubernetes APIを直接使用してクラスタと対話し、目的の状態を設定または変更することもできます。」というように、kubectlコマンドじゃなくても大丈夫ってなってますね....。
謎多きということで、今回は、ちょっと、Kubernetesについて整理したいと思います。
そして、今回も全部解決できてません...なので、お時間のある方のみご照覧ください。
Kubernetesとは...まず、Kubernetes clusters ありき？
なんか、みんな当たり前のように、Kubernetes clusters とか、クラスタって言葉を使ってるんだけど、これってどういうこと？
クラスタリング（Clustering）とは？
cluster という言葉からも分かるように、「クラスタリング」という概念が関わってくるようです。
Wikipediaによると、
ソフトウェアの点からみれば、クラスタリングは信頼性を得る為（1台のマシンが動作しなくなっても他がその作業を引き継ぐ）、またはコンピュータの非常に高い性能を廉価に得る1手段として利用される。コンピュータ・クラスターを参照。
⇧ コンピュータ・クラスターはというと、
コンピュータ・クラスターとは、複数のコンピュータを結合し、クラスター（葡萄の房）のようにひとまとまりとしたシステムのこと。単に「クラスター」または「クラスタリング」とも呼ばれる。1台のコンピュータでは得られないような、強力な計算性能や可用性を得ることができる。コンピュータ・クラスターは、クラスタリングを実現するためのハードウェアやソフトウェアなどにより構成される。
となってますね。
プラズマクラスターとかは、プラズマが複数集まってる状態ってことですかね。
プラズマクラスター（Plasmacluster）は、家電メーカーシャープが開発した、プラズマ放電により活性酸素を発生させ、＋（プラス）と－（マイナス）のプラズマクラスターイオンを作り、空気中に放出するプラズマクラスター技術を総称するものであり、また、シャープによる造語である。この呼称は、シャープにより商標登録されている。
⇧ 「プラズマクラスターはシャープだけ～」...、う、う～ん...よく分からん。
⇧ 上記サイト様によりますと、
「プラズマクラスター」は、シャープ独自の空気浄化技術です。水分子に囲まれたクラスター状（ぶどうのふさ状）のイオンを発生させることで、除菌・消臭などに効果があることが知られていました。
今度の狙いはカビだって? シャープ「プラズマクラスター」新たな効果を示した3つの実験 | GetNavi web ゲットナビ
ということで、クラスター上のイオン。クラスタリング（Clustering）ですね～。
すみません、脱線しました。
また、1台のサーバーだけだと、そのサーバーが故障した際に、システムを止めざるを得なくなります。しかし、システムの運用を止めることができない場合も多く、1台のサーバーだけで運用するには問題があります。
そこで、多数のサーバーを組み合わせることがよく行われています。このような仕組みのことを、「クラスタリング」（Clustering）と呼びます。
⇧ 上記サイト様によりますと、複数サーバーを組み合わせて運用管理していく仕組みのことをクラスタリング（Clustering）というようです。
Kubernetesのクラスタは、何を指し示している？結局、Kubernetes clusterって？
クラスタリング（Clustering）が、複数のサーバーをクラスタとして捉えているってことは何となく分かったとして、Kubernetes においてのクラスタとは？
A set of machines, called nodes, that run containerized applications managed by Kubernetes.
A cluster has several worker nodes and at least one master node.
⇧ Kubernetesの公式サイトによりますと、
「クラスタには、複数のワーカーノードと少なくとも1つのマスターノードがあります。」
とあります。
⇧ 上記サイト様を参考にさせていただき、
あくまでイメージですが、イメージ的には、
⇧ 上記みたいな感じが実現できると仮定すると、Master Nodeと各Nodeを含んだ構成1つがクラスタ（kubernetes cluster）の最小構成で、そのクラスタが複数集まった構成をKubernetes clusters というのではないかと...推測でしかないけど。
⇧ 上記サイト様がいろいろと詳しいです。
Kubernetesのリソースとは？
Kubernetes クラスタの構成として、Master Nodeと最低限１つのNodeがあればOKということが分かりました。（MinikubeでKubernetesの環境を作った場合は、シングルノードなので、クラスタとしての条件をギリギリ満たしているってことですかね）。
で、Kubernetesで何かを行うには、YAML形式で書かれたManifestファイルに記述を行って、kubectlコマンドを実行してMaster Nodeに「リソース」の登録を行う必要があるようです。
⇧ 上記サイト様によりますと、「リソース」は大きく分けて、
| リソース | 内容 |
|---|---|
| Workloadsリソース | コンテナの実行に関するリソース |
| Discovery＆LBリソース | コンテナを外部公開するようなエンドポイントを提供するリソース |
| Config＆Storageリソース | 設定・機密情報・永続化ボリュームなどに関するリソース |
| Clusterリソース | セキュリティやクォータなどに関するリソース |
| Metadataリソース | リソースを操作する系統のリソース |
の5つが存在するようです。
で、まさに、いまコンテナの実行を行いたいので、Workloadsリソースですが、
- Pod
- ReplicationController
- ReplicaSet
- Deployment
- DaemonSet
- StatefulSet
- Job
- CronJob
全部で8種類のWorkloadsリソースが存在するそうな。（Kubernetesが内部で利用しているものは除く）。
認証情報
ちょっと、脱線。kubectlコマンドで、Master Nodeとやり取りしてましたが、
kubectlがKubernetes Masterとやり取りを行う際には、接続先サーバの情報や認証情報などが必要となります。デフォルトではkubectlは「~/.kube/config」に書かれている情報をもとに接続を行います。~/.kube/configもYAML Maniestと同じフォーマットとなっており、下記のような形で書かれています。
⇧ 上記サイト様によりますと、「C:¥Users¥ユーザー名¥.kube/config」ファイル（Windowsの場合のconfigファイルの場所）に情報が設定されていたので、MinikubeでKubernetes環境が構築された仮想マシンに対して操作ができていたようです。
MinikubeでKubernetesの環境を構築したときに、自動で生成されるファイルらしいです。
とりあえず、Kubernetesの環境が構築された仮想マシンを起動...でエラー
なんか、エラー...。
どうやら、「サクラエディタ」で「C:¥Users¥ユーザー名¥.kube/config」を開いてたのがいけなかったらしい...サクラさん、やってくれますね。
サクラエディタで開いていた「C:¥Users¥ユーザー名¥.kube/config」を閉じてもう一回、Kubernetes環境の構築された仮想マシンの起動。
⇧ 今度はOK。Kubernetesのクラスタも準備OK的な感じっぽいですね。
Kubernetesの環境が構築された仮想マシンが起動しています。
Kubernetes環境が構築された仮想マシンにログイン
とりあえず、Minikubeを利用してKubernetes環境を構築した仮想マシンへは、
minikube ssh
でsshログインできるようです。
ちなみに、普通のsshコマンドでログインする場合は、
| ユーザー名 | docker |
|---|---|
| パスワード | tcuser |
⇧ デフォルトだと、仮想マシンのログインユーザー名「docker」、パスワード「tcuser」 が設定されているようです。
VirtualBoxで用意されているVBoxManageコマンドで、仮想マシンのIPアドレスと、
NIC（Network Interface Card）、つまりネットワークを調べて、
ネットワークが、NATのほうで接続できるんじゃなかろうか...ということで、「VirtualBox/GuestInfo/Net/1/V4/IP」の「value: 192.168.99.100」を接続先の仮想マシンのIPアドレスとしていきます。
「"C:¥Users¥ユーザー名¥.minikube¥machines¥minikube¥config.json"」の「"IPAddress"」でも仮想マシンのIPアドレスの確認ができます。
⇧ 「ユーザー名」「パスワード」ともに「minikube」でいけると勘違いして失敗。
今度は、成功。
Deploymentとは？
前回、kubectl run でコンテナ化アプリケーションのデプロイができるらしいところまで、なんとなく調査できたんですが、
⇧ 上記サイト様によりますと、kubectl run を実行することで、Deploymentというものができるそうです。
で、自分が気になったのは、特に、yamlファイルとかに設定せずに、kubectl run でコンテナimageを取得して、コンテナ化アプリケーションのデプロイしてるって情報が多いという...。
hawksnowlog.blogspot.com⇧ 上記サイト様によりますと、minikubeの設定で、デフォルトで利用されるimageリポジトリが、Docker Hub に設定されていたらしい...。
docker info | grep Registry
⇧ ユーザー名もdockerだったりと、Docker色がまだ色濃く残っていますね。
というわけで、
kubectl run [deploymentに指定したい名前] --image=[コンテナimage]
と、[コンテナimage]の部分に、Docker Hubに存在するコンテナimageを指定すれば、コンテナ化アプリケーションが出来上がるかと。
では、Docker Hubでコンテナimageを探さねばなのですが、Javaに関するものは、
⇧ 上記サイト様によりますと、Docker Hub の場合、OpenJDKを利用していく感じになるのではないかということです。
⇧ Oracle JDK は、有料になるって話が出てましたが、開発用途に限っては、Java SE 11以降も無償で使えるのかな？
（2018年6月28日 時点）
Beginning with Oracle Java SE 11 (18.9 LTS), the Oracle JDK will continue to be available royalty-free for development, testing, prototyping or demonstrating purposes.
⇧ 開発中に限っては、ロイヤリティー・フリーとしてくれるようです、ありがたや～。
そして、Java 10において、「ローカル変数型推論」が出たようですね。
⇧ 上記サイト様が詳しいです。
それにしても、せっかくの型安全の文化が...どっちかというと、PHPのvar_dumpみたいな機能を先に作ってくれたら良かったのに...。
kubectl run で、Java 10を導入してみたいのだけど...
話が脱線しましたが、とりあえず、Javaを導入してみようと思いますが、Minikubeで作成された仮想マシンのOSはどうなっているのか？
cat /proc/version
もうちょい詳しく。
cat /etc/os-release
Buildrootって...初めて聞きますな。
Buildroot is primarily intended to be used with small or embedded systems based on various computer architectures and instruction set architectures (ISAs), including x86, ARM, MIPS and PowerPC.
⇧ Wikipediaさんによりますと、組み込み系のシステム向けの用途として考えられているものらしい...x86にも対応してるってことで普通のPCでも使えると...。
⇧ 上記サイト様によりますと、ソースコードディストリビューション というものらしい。内部でBusyBoxなんかを使ってるらしいです。
なので、
⇧ BusyBoxで使えるコマンドは、利用できるってことかしら？
と思ったら、
The first step when using Buildroot is to create a configuration. Buildroot has a nice configuration tool similar to the one you can find in the Linux kernel or in BusyBox.
と言っているけど、
Enabling the BR2_INIT_BUSYBOX will ensure BusyBox will build and install its init program.
とも言っている。後者の論だと、BusyBoxが、Buildrootにインストールされてるってことになる気がするんだけど...。
どっちにしろ、
なんかのメジャーどころのディストリビューションと違って、パッケージ管理ツール（CentOSとかだと、yum）みたいなものが無さそうな気が。
と思ったら、
Buildroot is designed to run on Linux systems.
While Buildroot itself will build most host packages it needs for the compilation, certain standard Linux utilities are expected to be already installed on the host system. Below you will find an overview of the mandatory and optional packages (note that package names may vary between distributions).
⇧ なんか、 Buildrootは、メジャーどころというか、通常のディストリビューションが利用されるのを想定してるような感じですかね。
「特定の標準Linuxユーティリティはすでにホストシステムにインストールされていることが予想されます。以下に、必須パッケージとオプションパッケージの概要を示します」の中に、
build-essential(only for Debian based systems)
とか、あるってことは、Debian 使ってたら、これインストールしといて的な話だと思われますしね。
心置きなく、メジャーどころのディストリビューションをインストールして大丈夫ってことですかね。
⇧ 上記サイト様でも、メジャーどころのディストリビューション入れとりますね。
自作のコンテナimageも使えるらしいという
時間の関係上、翌日へ。
で、翌日、仮想マシンを起動。VirtualBoxで用意されているVBoxManageコマンドでも起動できるようですが（そして、悪夢のはじまり）、後述のdocker damoneに上手く連携できない問題が起こるので、「minikube start」で起動するようにしてください。
どうやら、「Minikube start」コマンドが、Kubernetes clusterの起動を行っていてくれてたようです。
kubernetes clusterとdocker damoneの関連はよく分かりませんが、minikubeがいろいろやってくれているようです。
⇩ なので、ここからしばらくは、失敗が繰り広げられます。
VBoxManage startvm [仮想マシン名、またはuuid] --type headless
で、コンテナimageですが、自作のものを使えるらしいです。
⇧ 上記サイト様によりますと、DockerFileというものから、コンテナimageを作成できるらしい。
⇧ 上記サイト様によりますと、dockerの場合、コンテナimageの作成方法は、
- コンテナからイメージを作成する
- 既に存在するコンテナ化アプリケーションを元に、コンテナimageを作成
- Dockerfileをビルドしてイメージを作成する
- Dockerfileという名前のファイルを作成・編集したものを元に、コンテナimageを作成
の どちらかでいけるようです。
今回は、「2. Dockerfileをビルドしてイメージを作成」でトライしたいと思います。
そのためには、Dockerを利用できるようにする必要があるのですが、MinikubeにはDockerが内臓されているので、Windowsの場合は、
minikube docker-env
を行った後に、
REM Run this command to configure your shell:
REM @FOR /f "tokens=*" %i IN ('minikube docker-env') DO @%i
「@FOR /f "tokens=*" %i IN ('minikube docker-env') DO @%i」を実行して、とあるので、
@FOR /f "tokens=*" %i IN ('minikube docker-env') DO @%i
⇧ で、「docker ps」したら、「ターゲットマシンが積極的にそれを拒否したため、接続できませんでした。」って...傷つく言葉が。
ちなみに、dockerのCLIコマンドは、minikube側が用意してくれてるのかが不明（自分の場合は、前にDocker Toolboxをインストールしているので、そっちのdocker CLIが使われてるのか、minikube側が用意しているdocker CLIなのかが判断できず。）
⇧ そして、問題はサーバー側っすね。
⇧ 同じような問題かな～、解決できてないのか、クローズされとらんし...。いや～、DockerのWindowsに対する状況が、まったく進んでない気が...。
⇧ 「さくらインターネット」のサイトでは、問題なく動いてるっぽいんですが...。
⇧ 上記サイト様のダンディーはお方の修正版のコマンドを試したところ、
@FOR /f "tokens=* delims=^L" %i IN ('minikube docker-env') DO %i
⇧ なんか設定してるっぽいけど、その後、docker versionしてみるもエラーは変わらず。
そもそも、公式サイトには、Windowsの場合の手順がナッシィングなんすけど。
Reusing the Docker daemon
When using a single VM of Kubernetes, it’s really handy to reuse the minikube’s built-in Docker daemon; as this means you don’t have to build a docker registry on your host machine and push the image into it - you can just build inside the same docker daemon as minikube which speeds up local experiments. Just make sure you tag your Docker image with something other than ‘latest’ and use that tag while you pull the image. Otherwise, if you do not specify version of your image, it will be assumed as :latest, with pull image policy of Always correspondingly, which may eventually result in ErrImagePull as you may not have any versions of your Docker image out there in the default docker registry (usually DockerHub) yet.
To be able to work with the docker daemon on your mac/linux host use the docker-env command in your shell:
eval $(minikube docker-env)⇧ Windowsは、除け者かい。
⇧ 上記サイト様によりますと、Kubernetesが設定ファイルの場所が分からんと...そんなことある？
ちなみに、macやLinuxだと「eval $(minikube docker-env)」でいけるのですが、Windowsの場合（コマンドプロンプト、Power Shellなど）だと、
⇧ はい、エラー。
⇧ Windowsのコマンドプロンプト、Power Shellとかだと「eval」が使えない...前にdockerを利用してたときも起きてた気が...。
⇧ 上記の方法を試すも、まったく解決できず...。前に、dockerを使ってたときは、ConEmu入れてMsys2のgit導入後のbashという環境で試してた気が...。
そして、原因が判明。
Minkubeの仕組みは分からんのですが、どうやら、VBoxManageコマンドで仮想マシンを起動したのがいけなかったようです。（いや～...哀しくなりますね）
Minikubeを利用して仮想マシンを起動しないと、Kubernetes clusterが動き出さないのようでした。
あくまで、Minikubeを利用してDockerを利用する場合は、Minikubeが内蔵しているDocker damoneを利用することになるため、Kubernetes clusterが起動していないと、Kubernetes cluster環境の中にあるDocker damoneの起動が不可能ってことですね。
一旦、仮想マシンを停止し、
VBoxManage controlvm [仮想マシン名、またはuuid] acpipowerbutton
「minikube start」コマンドで、仮想マシンを再起動。
VBoxManage controlvm [仮想マシン名、またはuuid] acpipowerbutton
⇧ 失敗はここまで。
改めて、minikube start で仮想マシンを起動します。
MinikubeでKubernetes環境が構築された仮想マシンに内蔵のDockerに対して、環境変数とかも、一応、もう一回設定。
⇧ 今度は、Docker damoneも起動できてるっぽいです。
それでは、気を取り直して、Dockerfileの作成ですかね。
ちなみに、
⇧ 上記サイト様によりますと、Googleが、Dockerのコンテナimageを自動で生成してくれるツール「Jib」をオープンソースで公開したそうな。
⇧ Docker damoneに依存しないで、コンテナimageを作成できるツールも公開されたそうな。
時間のあるときに試してみたいですね。
では、Dockerfileですが、作成場所はどこでも良いみたいです。なので、今回は、「C:¥Users¥ユーザー名¥.minikube¥machines¥minikube¥minikube」フォルダの中に、「Dockerfile」を作成。
⇧ 上記サイト様を参考に、Dockerfile を編集していきます。
その前に、JDKの情報を確認。
http://www.oracle.com/technetwork/java/javase/downloads/index.html にアクセスして、
OracleのJDKのダウンロードページに来るので、上記のJDK 10をクリック。
ページ遷移したらば、「Accept License Agreement」にチェック。
そしたらば、「jdk-xx.x.x_linux-x64_bin_rpm」上で、右クリックし「リンクのアドレスをコピー（E）」。
で、適当なテキストエディターに張り付けると、
data-unlink="">http://download.oracle.com/otn-pub/java/jdk/10.0.2+13/19aef61b38124481863b1413dce1855f/jdk-10.0.2_linux-x64_bin.rpm
みたいな感じのURLになっています。
⇧ 図の中で、URLのそれぞれの部分に付けてる名前は、適当です。（後述するDockerfileの中で、変数として使うために適当な名前をつけてます）
あと、OSは、CentOS 7.5を試してみますか。
https://hub.docker.com/_/centos/ がOfficialなCentOSのDockerのコンテナimageのようです。
⇧ 「centos7.5.1804」という名前を、DockerfileのFromに指定。
Dockerfileの中身は、
# ベースイメージ（base image）の指定
# CentOS7.5のイメージを指定
FROM centos7.5.1804
# "ARG"で、Dockerfileの中でのみ有効な変数を宣言
ARG jdk_version=10.0.2
ARG jdk_build_no=13
ARG jdk_hash_value=19aef61b38124481863b1413dce1855f
ARG jdk_rpm=jdk-${jdk_version}_linux-x64_bin.rpm
# Javaのための環境変数を設定
ENV JAVA_HOME /usr/java/default
# wgetコマンドをyumでインストール
# インストールしたwgetでJavaのダウンロード
RUN yum install -y wget && \
wget -q \
--no-check-certificate \
--no-cookies \
--header "Cookie: oraclelicense=accept-securebackup-cookie" \
http://download.oracle.com/otn-pub/java/jdk/${jdk_version}+${jdk_build_no}/${jdk_hash_value}/${jdk_rpm} && \
rpm -ivh ${jdk_rpm}
CMD "/bin/bash"
みたいな感じになるかと。
ちなみに、CentOSのパッケージ管理ツールであるyumコマンドは、
Yum (Yellowdog Updater Modified)
って言うらしいですね。
そして、JAVA_HOMEのパスですが、
⇧ 上記サイト様によりますと、
JAVA_HOMEには/usr/java/defaultをセットしておきます。最新のJDKをインストールした時に自動で切り替わるためです。古いバージョンを使用したい場合は手動で切り替える必要があります。
ということらしいです。
ファイルが編集できたらば、「ファイル（F）」>「名前を付けて保存（A）...」。
「文字コードセット（C）:」を「UTF-8」にしておきます。で、「保存（S）」。
そしたら、Dockerfileを配置している場所に移動します。（移動しなくても大丈夫ではあるのですが...）
cd C:\Users\Toshinobu\.minikube\machines\minikube\minikube
では、コンテナimageの作成。
docker build -t [イメージ名:タグ名] [Dockerfileのあるディレクトリ]
⇧ はい、エラー。
⇧ 上記サイト様によりますと、まず、pullしてローカル環境にCentOSのimageを持ってこないといけなかったみたいです。
なるほど、Docker Hubから直で引っ張てくるもんだと思い込んでました。
2018年9月8日（土）：追記 ↓ ここから
pullするコンテナimageは、自分の使用するバージョンだけを指定したほうが良さそうでしたかね。
CentOSのコンテナimageを扱ってるリポジトリを検索する場合は、
docker search centos
で、まず、リポジトリを 検索して、
curlコマンドで検索するしかないようです。
curl -s https://registry.hub.docker.com/v1/repositories/[docker searchした結果のNAME]/tags | sed "s/,/\n/g" | grep name | cut -d '"' -f 4
あとは、
docker pull centos.7.5.1804
みたいな感じで、自分の取得したいバージョンのものを指定してpullすれば、わざわざ、pull -a で全部のコンテナimageを取得する必要はなかったですね...
DockerHubのイメージのタグ一覧をコマンドで取得する | Mazn.net
⇧ 上記サイト様を参考にさせていただきました。
2018年9月8日（土）：追記 ↑ ここまで
docker pull -a centos
で、取得できたコンテナimageの一覧を確認 。
docker images
今度こそ、docker build。
⇧ はい、変わらずエラー...。なんだろう、ローカルのimageを参照できてないのかな？
ちょっと...解決できなかったので調査します。
次回に持ち越しで。中途半端で申し訳ないです。
2018年7月30日（月） 追記
普通に、DockerfileのFromのところで、タイプミスしてました...。
■間違い
FROM centos7.5.1804
■正解
FROM centos:7.5.1804
docker damoneを起動。
minikube docker-env
@FOR /f "tokens=*" %i IN ('minikube docker-env') DO @%i
docker damoneが動きました。
Dockerfileのあるディレクトリに移動。
docker imageの作成！
docker build -t [イメージ名:タグ名] [Dockerfileのあるディレクトリ]
警告が出てますね...
⇧ 上記サイト様によりますと、
どうやらrpmの鍵が足りず、パッケージの真正性が証明できない事が原因のようですね。
Dockerfileを書いてみた(DockerForWindows上でCentOS7＋Apache＋PerlCGIのサーバ構築編)
とのことのようです。
⇧ あと、なんか、失敗してるっぽい...
⇧ パッケージ管理ツールが、apt-getだから、Ubuntu系っぽいけど、どうやら、キャッシュが残るのがいけないようで、システム自体を「update」してあげれば良いようです。
ということで、Dockerfileを修正します。
FROM centos:7.5.1804
ARG jdk_version=10.0.2
ARG jdk_build_no=13
ARG jdk_hash_value=19aef61b38124481863b1413dce1855f
ARG jdk_rpm=jdk-${jdk_version}_linux-x64_bin.rpm
ENV JAVA_HOME /usr/java/default
# yumコマンドによるキャッシュを削除
RUN yum clean all
# システム全体のアップデート
RUN yum -y update
# rpmの鍵を取得
RUN rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
RUN yum -y install wget
RUN wget -q \
--no-check-certificate \
--no-cookies \
--header "Cookie: oraclelicense=accept-securebackup-cookie" \
http://download.oracle.com/otn-pub/java/jdk/${jdk_version}+${jdk_build_no}/${jdk_hash_value}/${jdk_rpm} && \
rpm -ivh ${jdk_rpm}
CMD "/bin/bash"
修正して保存したら、再度、
docker build -t [イメージ名:タグ名] [Dockerfileのあるディレクトリ]
⇧ 処理は進んだけど、別の警告が出てますね。なんか、Javaのアイコンがないとかで、アイコンがcpできないって言ってますね。
まぁ、概ね問題ないでしょう、ということにしておきましょう。
一応、コンテナimageはできたみたいですね。肝心のコンテナimageがどこに配置されているのかは、来週に持ち越しで。調査します。
2018年7月31日（火） 追記
コンテナimageですが、
⇧ 上記サイト様によりますと、
docker info
で、確認できるそうな。Docker Root Dir にコンテナimage あるよって言ってますね。
docker のインストールに関する広範囲なシステム情報を表示します。表示する情報には、カーネルのバージョン、コンテナとイメージの数を含みます。表示するイメージの数とは、ユニークなイメージ数です。同じイメージで違うタグが付いている場合は、１つとして数えます。
⇧ Dockerの公式サイトでの情報。
というわけで、minikube startで、仮想マシンの起動とKubernetes clusterの起動。
Docker damoneを起動し、
docker info ～！
⇧ 「Docker Root Dir: /var/lib/docker」って...むっちゃ、仮想マシンの中ですやん...。
Docker は初回起動時に /var/lib/docker をマウントします。そして、この場所にデータ領域とメタ・データ領域を割り当てます。
Minikubeを使うと、仮想マシンの中にDockerのコンテナimageできるんですかね。
せっかくなんで、仮想マシンにsshログインして、ディレクトリの中身を確認しようとして...権限の問題で怒られる～。
sudo をコマンドの先頭につけて、
⇧ コンテナimageはいずこ...
一応、仮想マシン内ですが、コンテナimageはできてるようです。
docker images
⇧ コンテナimageがどこにあるかは分からず...。
本日はここまで～、仮想マシンから exitして、仮想マシンを停止。
また、調査します...。
今回はこのへんで。
