Docker imageファイルを移動したい、あと、Kubernetes環境をスクラッチで構築...の前に、仮想マシンのrootパーティションの拡張で躓く

時は流れまして...どうもボクです。半年ぐらい前に解決できてなかった問題の続きにトライしていこうかと。

常駐先の同僚の方が、エイフェックス・ツイン(Aphex Twin)が良いって仰っていて、そういえば大学の頃、『Richard D. James Album』よく聞いてたな、スクエアプッシャー (Squarepusher)もよく聞いてたな~と。

久々に聞いたけど今聞いても確かに良いですね。


Richard D. James Album [帯解説 / 国内盤CD] (BRC556)

⇧  ジャケットが相変わらず良い感じですね。

 


Ultravisitor [解説付き国内盤 / スペシャル・プライス / リイシュー盤] (BRC328)

⇧  スクエアプッシャーの『Iambic 9 Poetry』はむちゃくちゃ聞いてたな~、懐かしい15年ぐらい前か~。

 

はい、すみません、脱線しました。 

仮想マシンにDockerのimageがあるんだけど、それを別の仮想マシンに移動したいと。

Minikubeで作成された仮想マシンだと、作成後はDockerのデバイスサイズが変更できない問題(Minikube作成時点で、サイズを決めるしかない)があり、コンテナ化でエラーになってしまっていました。

ts0818.hatenablog.com

⇧  この回なんですが、Minikubeで、どうしても、dockerdコマンド(Dockerのdaemonを操作するコマンド)が動かないという...

致し方ないので、Minikube以外の仮想マシンでコンテナ化してみようってことで、Docker imageを移籍したいって話です。 

 

というわけで、今回は、Dockerのimageをファイルにして、別の仮想マシンに移動するにトライ。

Kubernetes環境のスクラッチ構築は、仮想マシンのrootパーティションの拡張ができず未解決なので、お時間のある方のみご照覧ください。

 

Dockerのimageをファイルに保存

まずは、Dockerのimageをファイルに保存するところからですかね。

uxmilk.jp

⇧  上記サイト様が詳しいです。

 

というわけで、とりあえず、Minikubeの仮想マシンを起動。

minikube start

f:id:ts0818:20181028152548p:plain

起動したらば、サーバ側のDockerを利用できるように、

minikube docker-env

指示されたコマンドを実行。

@FOR /f "tokens=*" %i IN ('minikube docker-env') DO @%i

f:id:ts0818:20181028153602p:plain

いまローカル上にあるDockerのimageを一覧表示。今回は、『local/cent7.5.1804-systemd』をファイルに保存したいと思います。

f:id:ts0818:20181028153700p:plain

いざ、保存。

docker save local/cent7.5.1804-systemd:7.5 > cent7.5.1804-systemd.tar

f:id:ts0818:20181028154333p:plain

保存されました。

f:id:ts0818:20181028154602p:plain

 

別の仮想マシン(Dockerが使える)を起動

今回は、Docker ToolBoxで作成された仮想マシンを起動します。

Docker ToolBoxをインストールしてない場合は、

qiita.com

⇧  上記サイト様が詳しいです。

ちなみに、Windows 10 Proとか、Hyper-Vが利用できる環境なら、『Docker for Windows』を利用する選択肢もあります、というか、そっちのほうが良いのではないかと、使ったことないから分からないけど。

では、上記サイト様の手順通り、「Kitmatic」というものを起動し、「DOCKER CLI」をクリックすると、

f:id:ts0818:20181028155254p:plain

Windowsだと、PowerShellが起動しますかね。「default」という仮想マシンが起動しています。

f:id:ts0818:20181028155412p:plain

VirtualBox Managerのほうでも「default」という仮想マシンが起動しているのが確認できます。

f:id:ts0818:20181028155536p:plain

で、Dockerのimageファイルを読み込もうとしたら、エラー。

qiita.com

⇧  ほんと、WindowsってLinux系と相性悪いですね~。

f:id:ts0818:20181028160345p:plain

⇧ 「<」は使えないらしい...しかも、「-i」とかオプション欲しいようです。

docker load -i "C:\Users\Toshinobu\cent7.5.1804-systemd.tar"

Dockerのimageファイルは移籍できたっぽい。

f:id:ts0818:20181028160742p:plain

Dockerfileで利用するDockerのimageが用意できたので、Dockerfileを使って、新たなDockerのimageを作成します。

Minikubeのときに用意していたDockerfileを利用していきます。ちなみに、自分の場合は、こんな場所に用意しています。

f:id:ts0818:20181028161027p:plain

Dockerfileで読み込んでる他のファイルなどは、 

ts0818.hatenablog.com

⇧  こちらを参考にしていただければ。 

 

Oracle JDK 10のサポートが終了していてダウンロードできなくなっていたようです...

f:id:ts0818:20181028163047p:plain

Java SE Development Kit 11- - Downloads で、「jdk-11.0.1_linux-x64_bin.rpm」のリンクアドレスをコピー。

なんか、Apache Httpdのバージョンも、2.4.34から2.4.37になってた(2018年9月の話だから、いまは更にバージョンが上がってると思われます。)...使うアプリケーションはローカルに落としといて、そっちを参照しとかないと駄目っすね。

開発なんかでは、きっとローカル環境に固定したバージョンを保存しておくんでしょうね...。

Dockerfileを修正します。各アプリケーションのバージョンとかは、最新に合わせていただくということで。(この内容を書いたのが、2018年の9月頃だった気がするので、おそらく諸々のパッケージのバージョンが見つからんってなると思われ...)

FROM local/cent7.5.1804-systemd:7.5

#□□□ JAVAのインストール □□□#
# Java10用の変数(バージョン情報とか)
ARG jdk_version=11.0.1
ARG jdk_build_no=13
ARG jdk_hash_value=90cf5d8f270a4347a95050320eef3fb7
ARG jdk_rpm=jdk-${jdk_version}_linux-x64_bin.rpm

# Javaの環境変数のためのパス
ENV JAVA_HOME /usr/java/default

# yumのキャッシュをクリア
RUN yum clean all

# EPELリポジトリを利用している場合は、EPELリポジトリをアップデート
# RUN yum -y update epel-release --disablerepo=epel

# rmpのパッケージの差分を管理のために
RUN yum -y install deltarpm 
# システム全体のアップデート
RUN yum -y update

# GPGキー(「GnuPG」(GNU Privacy Guard)という暗号化ソフトで生成される公開鍵。)のインストール
# ↑ パッケージが正しい配布先のものかどうかのチェックするもの
RUN rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
# wgetコマンドをインストール
RUN yum -y install wget

# JDK10のインストール
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}


#□□□ Tomcatのインストール □□□#
# Tomcat9用の変数(バージョン情報とか)
ARG tom_magor=9
ARG tom_version=9.0.12

# Tomcatの環境変数のためのパス
ENV CATALINA_HOME /usr/local/tomcat-${tom_version}

# 環境変数に追加するためのパスを用意
ENV PATH $PATH:$JAVA_HOME/bin:$CATALINA_HOME/bin

# Javaのクラスパスを用意
ENV CLASSPATH=.:$JAVA_HOME/jre/lib:$JAVA_HOME/lib:$JAVA_HOME/lib/tools.jar:$CATALINA_HOME/common/lib

# Javaのパス、Javaのクラスパス、Tomcatのパスを環境変数に追加
RUN export JAVA_HOME PATH CLASSPATH CATALINA_HOME

# Tomcatのダウンロード、展開(解凍)
RUN wget http://www-eu.apache.org/dist/tomcat/tomcat-${tom_magor}/v${tom_version}/bin/apache-tomcat-${tom_version}.tar.gz && \
    tar -xvzf apache-tomcat-${tom_version}.tar.gz && \
    mv apache-tomcat-${tom_version} /usr/local/tomcat-${tom_version}

# ユーザー「tomcat」を作成
RUN useradd -s /sbin/nologin tomcat

# Apache Tomcatの所有者を、ユーザー「tomcat」に設定
RUN chown -R tomcat:tomcat /usr/local/tomcat-${tom_version}

# host(Windows)側に用意したTomcatのserver.xmlを、コンテナ側にコピー
ADD ./tomcat_conf/server.xml /usr/local/tomcat-${tom_version}/conf/server.xml

# 起動スクリプト用
RUN cp /usr/local/tomcat-${tom_version}/bin/catalina.sh /etc/init.d/tomcat-${tom_version}
RUN chmod 775 /etc/init.d/tomcat-${tom_version}


#□□□ Apache Httpdのインストール □□□#
# Apache Httpdのインストールに必要な基本コマンド、開発ツールのインストール
RUN yum groups mark convert
RUN yum -y groupinstall base
RUN yum -y groupinstall development
RUN yum -y update

# Nghttp2に必要なライブラリのインストール
RUN yum -y install openssl-devel jansson-devel libev-devel c-ares-devel

#□□ Nghttp2のインストール □□#
# Nghttp2用の変数(バージョン情報とか)
ARG nghttp2_version=1.32.0

# Nghttp2最新版の情報 -> https://github.com/tatsuhiro-t/nghttp2/releases/latest
# Nghttp2のダウンロードと展開(解凍)
RUN cd /usr/local/src/ && \
    wget https://github.com/nghttp2/nghttp2/releases/download/v${nghttp2_version}/nghttp2-${nghttp2_version}.tar.gz && \
    tar xvzf nghttp2-${nghttp2_version}.tar.gz

# Nghttp2をコンパイルしてインストール
# HTTP/2 のライブラリ「libnghttp2」が /usr/local/lib 以下にインストールされます。
# Nghttp2 関連のコマンドは /usr/local/bin 以下にインストールされます。
RUN cd /usr/local/src/nghttp2-${nghttp2_version}/ && \
    ./configure -enable-app && \
    make && \
    make install

#□□ Brotliのインストール □□#
# Brotli用の変数(バージョン情報とか)
ARG brotli_version=1.0.5

# Brotliのコンパイルに必要なcmakeのインストール
RUN yum -y install cmake

# Brotli最新版の情報 -> https://github.com/google/brotli/releases/latest
# Brotliのダウンロードと展開(解凍)
RUN cd /usr/local/src/ && \
    wget https://github.com/google/brotli/archive/v${brotli_version}.tar.gz && \
    tar xvzf v${brotli_version}.tar.gz

# Brotliをコンパイルしてインストール
# Brotli のライブラリが /usr/local/lib 以下にインストールされます。
RUN cd /usr/local/src/brotli-${brotli_version}/ && \
    mkdir out && cd out && \
    ../configure-cmake && \
    make && \
    make test && \
    make install

# ライブラリへのパス追加
RUN echo /usr/local/lib > /etc/ld.so.conf.d/usr-local-lib.conf
RUN ldconfig

#□□  curlの最新版のインストール □□#
# curl用の変数(バージョン情報とか)
ARG curl_version=7.61.0

# curl最新版の情報 -> https://curl.haxx.se/changes.html
# curlのダウンロードと展開(解凍)
RUN cd /usr/local/src/ && \
    wget https://curl.haxx.se/download/curl-${curl_version}.tar.gz && \
    tar xvzf curl-${curl_version}.tar.gz

# curlをコンパイルしてインストール
RUN cd /usr/local/src/curl-${curl_version}/ && \
    ./configure && \
    make && \
    make install

# Apche httpdのコンパイルに必要なパッケージのインストール
RUN yum -y install pcre-devel expat-devel
# APR、APRUの最新版の情報 -> http://apr.apache.org/
#□□  APR(Apache Portable Runtime)の最新版のインストール □□#
# APR(Apache Portable Runtime)用の変数(バージョン情報とか)
ARG apr_version=1.6.5

# ARPのダウンロードと展開(解凍)
RUN cd /usr/local/src/ && \
    wget http://www-us.apache.org/dist//apr/apr-${apr_version}.tar.gz && \
    tar xvzf apr-${apr_version}.tar.gz

# APRをコンパイルしてインストール
RUN cd /usr/local/src/apr-${apr_version}/ && \
    ./configure && \
    make && \
    make install

#□□  APR-util(Apache Portable Runtime Utility)の最新版のインストール □□#
# APR-util(Apache Portable Runtime Utility)用の変数(バージョン情報とか)
ARG apr_util_version=1.6.1

# ARP-utilのダウンロードと展開(解凍)
RUN cd /usr/local/src/ && \
    wget http://www-us.apache.org/dist//apr/apr-util-${apr_util_version}.tar.gz && \
    tar xvzf apr-util-${apr_util_version}.tar.gz

# APR-utilをコンパイルしてインストール
RUN cd /usr/local/src/apr-util-${apr_util_version}/ && \
    ./configure --with-apr=/usr/local/apr && \
    make && \
    make install

# Apache httpd用の変数(バージョン情報とか)
ARG httpd_version=2.4.37

# Apache httpdのダウンロードと展開(解凍)
RUN cd /usr/local/src/ && \
    wget http://www-us.apache.org/dist//httpd/httpd-${httpd_version}.tar.gz && \
    tar xvzf httpd-${httpd_version}.tar.gz

# Apache httpdをコンパイルしてインストール
RUN cd /usr/local/src/httpd-${httpd_version}/ && \
    ./configure \
        --enable-http2 \
        --enable-brotli \
        --with-brotli=/usr/local/lib \
        --enable-ssl \
        --enable-md \
        --with-apr=/usr/local/apr \
        --with-apr-util=/usr/local/apr \
        --enable-so \
        --enable-mods-shared=all \
        --enable-mpms-shared=all \
        --enable-proxy \
        --enable-proxy-ajp \
        --enable-headers && \
    make && \
    make install

# Apache Httpdの設定ファイルのバックアップ
RUN mv -i /usr/local/apache2/conf/httpd.conf /usr/local/apache2/conf/httpd.conf.org
RUN mv -i /usr/local/apache2/conf/extra/httpd-ssl.conf /usr/local/apache2/conf/extra/httpd-ssl.conf.org

# host(Windows)側に用意したhttpdの設定ファイルを、コンテナ側にコピー
# Dockerfile内で利用の場合、docker cpはADDになる
ADD ./httpd_config/httpd.conf /usr/local/apache2/conf/httpd.conf
ADD ./httpd_config/httpd_ssl.conf /usr/local/apache2/conf/extra/httpd_ssl.conf

# apache 設定(httpd.confで、apacheユーザー、apacheグループを設定してるので、割愛)
# RUN chown -R apache:apache /var/www/html/

# apxs(APache eXtenSion tool)を含むhttpd-develのインストール
RUN yum -y install httpd-devel

# mod_systemd.cのコンパイルに必要なライブラリのインストール
RUN yum -y install systemd-devel

# Apache Httpdのモジュール、mod_systemd.cのダウンロード、コンパイル
RUN cd /usr/local/src/httpd-${httpd_version}/modules/arch/unix && \
    wget "https://svn.apache.org/viewvc/httpd/httpd/trunk/modules/arch/unix/mod_systemd.c?view=co" -O mod_systemd.c && \
    /usr/local/apache2/bin/apxs -c mod_systemd.c -I /usr/include/systemd/sd-daemon.h && \
    libtool \
      --silent \
      --mode=compile gcc -std=gnu99 -prefer-pic -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong \
      --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_LARGEFILE64_SOURCE -DLINUX -D_REENTRANT -D_GNU_SOURCE -pthread -I/usr/local/apache2/include -I/usr/local/apache2/include -I/usr/local/apache2/include -I/usr/local/apr/include/apr-1 -c -o mod_systemd.lo mod_systemd.c && \
    touch mod_systemd.slo && \
    libtool \
      --silent \
      --mode=link gcc -std=gnu99 -Wl,-z,relro,-z,now,-L/usr/lib64 -o mod_systemd.la -rpath /usr/local/apache2/modules -module -avoid-version mod_systemd.lo && \
    libtool \
      --silent \
      --mode=link gcc -std=gnu99 -Wl,-z,relro,-z,now,-L/usr/lib64 -o mod_systemd.la -rpath /usr/local/apache2/modules -module -avoid-version mod_systemd.lo -lsystemd-daemon

# mod_systemdのインストール
RUN cd /usr/local/src/httpd-${httpd_version}/modules/arch/unix && \
    /usr/local/apache2/bin/apxs -i -a -n systemd mod_systemd.la

# apache httpdのモジュールを共有ライブラリとして登録
RUN echo /usr/local/apache2/modules >> /etc/ld.so.conf
# スーパーユーザーに切り替え
USER root
# 共有ライブラリの依存関係情報を更新
RUN ldconfig

# host(Windows)側に用意したhttpdをサービスとして起動するための設定ファイルを、コンテナ側にコピー
ADD ./httpd_config/httpd.service /etc/systemd/system/httpd.service

# iptablesのインストール
RUN yum -y install iptables-services

# host(Windows)側に用意したiptablesの設定ファイルを、コンテナ側にコピー
ADD ./firewall/enforce_rules.sh /bin/firewall/enforce_rules.sh

# iptablesの設定。(HTTP(80/tcp) と HTTPS(443/tcp)の開放)
ENV CHAIN_NAME "CONTAINER-FIREWALL"
ENV ACCEPT_PORT "80,443"

# iptables、httpd、Tomcatの起動スクリプトの作成
RUN echo -e $'/usr/sbin/init\n\
systemctl daemon-reload\n\
sh /bin/firewall/enforce_rules.sh\n\
systemctl start httpd\n\
systemctl enable httpd\n\
/etc/init.d/tomcat-9.0.12 start\n\
/bin/bash' > /startService.sh

# スクリプトの権限
RUN chmod o+x /startService.sh

# 公開ポート(apache:80,tomcat:8888で空けてる)
EXPOSE 80 8888
    
CMD ["/startService.sh"]

では、Dockerfileの場所まで移動し、

docker build --rm --no-cache -t cent_java_tom_httpd:10 .

f:id:ts0818:20181028161918p:plain

f:id:ts0818:20181028181628p:plain

二回ほど失敗したので、「<none>」なものができていますが、「cent_java_tom_httpd」というREPOSITORY名でimageファイルができました。

f:id:ts0818:20181028182633p:plain

 

Kubernetesの環境構築...の前にDocker ToolBoxのアップグレード

MinikubeのKubernetesだとなんかいろいろ制限がありありなので、今回は、スクラッチ(まっさらな状態から構築) で、Kubernetes環境を作りたいかと。

komeiy.hatenablog.com

⇧  上記サイト様を参考にさせていただきました。

 

とりあえず、Docker ToolBoxで用意された仮想マシンsshログイン。

docker-machine ssh    

f:id:ts0818:20181028191336p:plain

⇧  Dockerのバージョンが、古っ...2017年5月って

 

shuaib.me

⇧  上記サイト様によりますと、最新のDocker ToolBoxのインストーラーをインストーラーしてまずは、Docker ToolBox をアップデートし、そのあとで、Docker ToolBoxで作成された仮想マシンをアップデートすることで、仮想マシン内のDockerもアップデートできるってことらしい...面倒くさ...

とりあえず、Chocolatey でアップグレードできるらしい。

Chocolatey Gallery | Docker Toolbox 18.03.0

f:id:ts0818:20181028192941p:plain

コマンドプロンプトを管理者権限で起動し、いざ!

choco upgrade docker-toolbox

f:id:ts0818:20181028193210p:plain

ダイアログが出て、インストールが始まります。

f:id:ts0818:20181028193303p:plain

f:id:ts0818:20181028193402p:plain

⇧  Git for Windowsもインストールされるっぽい。

間違ってPowerShell閉じちゃったので、コマンドプロンプトを普通に起動して、Docker ToolBoxで作成された仮想マシンを停止。 

docker-machine stop default

f:id:ts0818:20181028193846p:plain

ToolBoxで作成された仮想マシンをアップグレード。 

docker-machine upgrade default

f:id:ts0818:20181028194035p:plain

f:id:ts0818:20181028194251p:plain

⇧  なんか、再起動までしてくれるらしい。

とりあえず、Docker ToolBoxで用意された仮想マシンsshログイン。

docker-machine ssh

f:id:ts0818:20181028194444p:plain

⇧  あたらしくなりました。

 

2019年3月16日(土)追記: ↓  ここから

だいぶ時が経ったので、Docker toolboxをまたアップグレードしました。

f:id:ts0818:20190316111318p:plain

f:id:ts0818:20190316111409p:plain

f:id:ts0818:20190316111457p:plain

仮想マシンもアップグレードで。

f:id:ts0818:20190316111937p:plain

f:id:ts0818:20190316112019p:plain

f:id:ts0818:20190316113005p:plain

⇧  はい、エラー...リトライアウト(再接続できる回数を超える)してると...

仮想マシン自体は起動しているらしい。

f:id:ts0818:20190316121724p:plain

 

qiita.com

⇧  上記サイト様によりますと、IPアドレスマッピングがおかしくなってると。

ちなみに、Docker ToolBox で作成される仮想マシンに関する情報とかは、通常のVirtualBoxのコマンドで作成される仮想マシンと場所が異なると。

■ Docker ToolBoxで作成された仮想マシンの情報

f:id:ts0818:20190316124145p:plain

VirtualBoxで作成された仮想マシンの情報

f:id:ts0818:20190316130839p:plain

 

そもそも、VirtualBoxで作成する仮想マシンでは、config.jsonなんかは存在しないと。秘密鍵・公開鍵なんかの情報も無いのは、docker daemonsshする必要が無いってことからなのかしら?

で、VirtualBox.xml には、VirtualBox Managerで表示される仮想マシンの全量が記載されてると...

f:id:ts0818:20190316125413p:plain

 

話が脱線しましたが、config.json を見てみたけど、よう分からんです...

stackoverflow.com

⇧  上記サイト様を参考に、仮想マシンを再作成しました。仮想マシンにいろいろアプリとかインストールされてると、環境が全部なかったことになるので使えない方法ではありますが...

f:id:ts0818:20190316134218p:plain

Docker Daemonが起動したようです。

そしたらば、

docker-machine env default   

で。(一回、間違えて、Docker deamonが動いてないのに、sshしてしまった。)

f:id:ts0818:20190316134600p:plain

Dockerのsshログインで、クジラさんが表示されなくなった模様。

f:id:ts0818:20190316135808p:plain

f:id:ts0818:20190316140057p:plain

2019年3月16日(土)追記: ↑  ここまで 


 

Kubernetesの環境構築

では、改めて、Docker ToolBoxの仮想マシンのOSは、

cat /etc/os-release

f:id:ts0818:20181028195052p:plain

Boot2Docker と。

The boot2docker CLI tool is long-since officially deprecated in favor of Docker Machine.

On the other hand, the boot2docker distribution (as in, boot2docker.iso) is in "maintenance mode". See https://github.com/boot2docker/boot2docker for more details.

It is highly recommended that users transition from Boot2Docker over to Docker for Mac or Docker for Windows instead.

http://boot2docker.io/

⇧  Docker ToolBoxってオワコンなの?でも、Windows 10 HomeだとDocker for Windows使えないし、Minikubeは色んな意味で使えない子だし...どうしろと?

まぁ、この問題は先送りで、問題の先送りは政治家の常套手段ですな。

 

2019年3月16日(土)追記: ↓  ここから

更新したDocker ToolBoxで。 

f:id:ts0818:20190316141209p:plain

OSは、Core Linux ということらしい。

f:id:ts0818:20190317101802p:plain

と思ったら、Boot2Docker ってことなのか?

f:id:ts0818:20190317103005p:plain

 

github.com

Boot2Docker is a lightweight Linux distribution made specifically to run Docker containers. It runs completely from RAM, is a ~45MB download and boots quickly.

GitHub - boot2docker/boot2docker: Lightweight Linux for Docker

⇧  上記サイト様によりますと、Linuxディストリビューションということらしい。 



 

Kubernetesをダウンロードします。

github.com

wget https://github.com/kubernetes/kubernetes/releases/download/v1.13.4/kubernetes.tar.gz

f:id:ts0818:20190316144805p:plain

仮想マシン内の、home/docker/ に、「kubernetes.tar.gz」がダウンロードされました。

展開(解凍)します。

tar -zxvf kubernetes.tar.gz

f:id:ts0818:20190316144938p:plain

f:id:ts0818:20190316145031p:plain

⇧  「kubernetesディレクトリに展開(解凍)されました。

さらに、「/home/docker/kubernetes/server/kubernetes-manifests.tar.gz」を展開(解凍)するらしい。

www.softel.co.jp


「-C」オプションで、展開先を指定できるそうな。

tar -zxvf ~/kubernetes/server/kubernetes-manifests.tar.gz -C /home/docker

f:id:ts0818:20190316145417p:plain

展開できて...ねぇじゃね~か~い!

f:id:ts0818:20190316145654p:plain

 

2019/5/1(水)追記:↓  ここから

認識が間違ってました。新しく、 

ts0818.hatenablog.com

⇧ の記事でいけました、すみません。

⇩  なので、以下の作業は不要でした。

2019/5/1(水)追記:↑  ここまで

 展開ですが、gzファイルに限りますが、

hacknote.jp

⇧  上記サイト様によりますと、「gunzip」ってコマンドがあれば、再帰的に展開してくれるらしい。

「gunzip」はインストールされてるらしいので、おりゃ~!

gunzip -rf ~/kubernetes.tar.gz

f:id:ts0818:20190316150016p:plain

はい、怒られました。「-r」オプションなんてないよ、と。

f:id:ts0818:20190316150046p:plain

というわけで、おりゃ~!

gunzip -f ~/kubernetes.tar.gz

f:id:ts0818:20190316150141p:plain

なるほど、確かに、gzファイルは展開されたけど、tarファイルはそのままの状態と...

結局、あと2回展開する必要があるから、1回分無駄っすかね...。

f:id:ts0818:20190316150522p:plain

kubernetes-manifests.tar.gz」って...「gunzip」で再帰的に展開されとらんやん...意味ね~。 

f:id:ts0818:20190316150724p:plain

そして、展開先を指定するも、

f:id:ts0818:20190316151238p:plain

指定した展開先とことなる場所にインストールされるという...Kubernetesの陰謀? 

f:id:ts0818:20190316151336p:plain

「/home/docker/kubernetes/gci-trusty」の中身を、「usr/local/bin」に移動すれば良いらしい。

f:id:ts0818:20190316151512p:plain

ファイルをまとめて移動したいな~、と思い、

www.atmarkit.co.jp

⇧  上記サイト様を参考にさせていただいたところ、

f:id:ts0818:20190316151642p:plain

「-T」オプションなんて無いらしいと...なんか、BusyBoxのmvコマンドは特殊なんですかね?

q.hatena.ne.jp

⇧  上記サイト様の方法でいけました。

mv ~/kubernetes/gci-trusty/* /usr/local/bin

f:id:ts0818:20190316151820p:plain

間違えました...sudo 付けないと権限で怒られると...

sudo mv ~/kubernetes/gci-trusty/* /usr/local/bin

f:id:ts0818:20190316152032p:plain

f:id:ts0818:20190316152418p:plain

2019/5/1(水)追記:↓  ここから

⇧  上記の作業は不要でした。 

2019/5/1(水)追記:↑  ここまで

 

 

とりあえず、Server側のKubernetesCluster環境として必要なものは、「kubeapi-server」に必要な「etcd(etc distributed) 」という分散KVS(Key Value Store)をインストールすれば良いらしい。KVSは、noSQLの1ジャンルらしいです。

https://github.com/etcd-io/etcd/releases で、「etcd-v3.3.12-linux-amd64.tar.gz」のリンクアドレスをコピー。

f:id:ts0818:20190316152720p:plain

f:id:ts0818:20190316153058p:plain

ダウンロードし、 

wget https://github.com/etcd-io/etcd/releases/download/v3.3.12/etcd-v3.3.12-linux-amd64.tar.gz

f:id:ts0818:20190316153402p:plain

展開(解凍)します。 

tar -xzvf etcd-v3.3.12-linux-amd64.tar.gz

f:id:ts0818:20190316153623p:plain

 

etcd~系のものを、「/usr/local/bin」に配置すれば良いらしい。

sudo mv ~/etcd-v3.3.12-linux-amd64/etcd* /usr/local/bin

f:id:ts0818:20190316153901p:plain

そしたらば、etcdを起動するのですが、

Single-node etcd cluster

./etcd --listen-client-urls=http://$PRIVATE_IP:2379 --advertise-client-urls=http://$PRIVATE_IP:2379

Replace PRIVATE_IP with your etcd client IP. 

https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/

⇧  いやいやいや、etcd client IPが何を指すかサッパリなんですが...まぁ、普通に考えたらクライアントマシンのIPということで、ここだとVirtualBox仮想マシンIPアドレスってことだと思われますが。 

 

qiita.com

⇧  上記サイト様が、Windowsでの仮想マシン(Docker含む)のIPの関係に詳しいですが、ifconfigコマンドで表示される「eth1」のIPが仮想マシンIPアドレス、つまりclient IPということになるかと。

Docker ToolBox で作成された仮想マシンIPアドレスを確認。

f:id:ts0818:20190316155647p:plain

では、etcd を起動。

etcd --listen-client-urls http://0.0.0.0:2379 --advertise-client-urls http://[仮想マシンのIPアドレス]:2379 &> /tmp/etcd.log &    

etcd が動いているか確認。

etcdctl cluster-health

f:id:ts0818:20190316155530p:plain

OKのようです。

etcd を起動するときのオプションなんかは、

qiita.com

⇧  上記サイト様が詳しいです。

 

一応、 ss -ltn で 2379 が開いていることも確認しておくと良いでしょう。

Kubernetes v1.11 を scratch install したら理解深まるじゃんって話 - ぽぽぽぽーんのネットワークとOSS

ss コマンドって? 

milestone-of-se.nesuke.com

ss は socket statistics の略で、netstatに替わる Linux標準のネットワークの状態確認コマンドです。初期はバグが多いと話題になっていたようですが、現状では netstat と大きな違いはありません。

linux【ss/netstat】コマンドの見方/オプション~Recv-Q/Send-Qやポート確認(Listen/Estab/Unconn),プロセス表示等~ | SEの道標

⇧  上記サイト様が詳しいです。 

というわけで、

ss -nltup    

f:id:ts0818:20190316160923p:plain

見方がよく分からんですが、etcd が動いてるらしいと。

 

続きまして、kube-apiserver の起動。etcd 以外のものについては、kubernetes.tar.gz に入っているようなので、インストールは済んでいるということらしいです。

kube-apiserver --etcd-servers=http://localhost:2379 --service-cluster-ip-range=192.168.199.0/24 --bind-address=0.0.0.0 --admission-control="" --insecure-bind-address=0.0.0.0 &> /tmp/apiserver.log &

f:id:ts0818:20190316162608p:plain

で、起動確認でエラー。

f:id:ts0818:20190316163504p:plain

 

なんか、仕様が変わってたらしい。

qiita.com

qiita.com

⇧  上記サイト様によりますと、いつのバージョンからは分からないのですが、スクリプトを実行することで、必要なものをインストールしないといけないらしい。

で、そのスクリプト群は、「kubernetes.tar.gz」を展開した時に作成される~/kubernetes/cluster/ に配置されてると。

f:id:ts0818:20190316200749p:plain

⇧  その中の、「get-kube-binaries.sh」ってスクリプトファイルを実行すれば良いらしい。

f:id:ts0818:20190316203427p:plain

f:id:ts0818:20190316203457p:plain

はい、エラー。

technote925.com

⇧  権限の問題らしい。

sudo 付けて再実施したら、何も加えるもの無いって...

f:id:ts0818:20190316203646p:plain

んで、「./kubernetes/server/kubernetes-server-linux-amd64.tar.gz」ってのが配置されてるので、展開すれば良いらしい。

f:id:ts0818:20190316203944p:plain

展開を試みるも、

f:id:ts0818:20190316205244p:plain

エラー。

qiita.com

inodeとは、UNIX系OSで使用されるファイルシステムの名称で、ファイルの所有者やアクセス権、サイズ、作成日時、場所などを管理しているもののことだそうだ。

No space left on device とエラーが出るときの対処法 - Qiita

⇧  上記サイト様を参考にチェケラー。

f:id:ts0818:20190316205630p:plain

f:id:ts0818:20190316205717p:plain

自分の場合は、/ の tempfs がいっぱいいっぱいらしい。

mimimopu.com

⇧  上記サイト様によりますと、tmpfs を調べてみようとのこと。

f:id:ts0818:20190316210911p:plain

etcd やん...

f:id:ts0818:20190316211327p:plain

もしや、kubernetesに必要ないろんなもんをインストールする前にetcd が起動してるのがマズイってこと?

で、etcd を止めてみようかと思ったんだけど、まさかの止める方法が無い...

とりあえず、プロセスをキルするしか無さそう...何だかな...

f:id:ts0818:20190316215006p:plain

キルして、プロセスは消えたけど、使用量が変わらず...

どうやら、/ のtmpfsって、

f:id:ts0818:20190316223420p:plain

/ のディレクトリってことらしい...tmpだけじゃないってことみたい。何てこった...etcd のプロセスを意味もなくキルしてしまったではないか...

 

ext.omo3.com

⇧  上記サイト様を参考に、サイズを使用量上位10位までに絞って見てみると。

キロバイト表示だと...計算しづらいということで、

f:id:ts0818:20190316224152p:plain

ガバイトだと、使用量上位10位だけで、「1386M」って...「890.4M」に比べて...使用率155.6%...100%超えてますやん...

f:id:ts0818:20190316224715p:plain


時間の都合上、翌日に。

で、仮想マシンの起動でエラー...

f:id:ts0818:20190317091139p:plain

 

qiita.com

⇧  上記サイト様によりますと、仮想マシンIPアドレスが変わってくるのが原因とのこと。

いけました。

f:id:ts0818:20190317091611p:plain

見事に、/home/docker のファイルは消えてますね。/home/docker フォルダは仮想マシンが起動するたびに、再作成されるってことですかね。

f:id:ts0818:20190317092112p:plain

んで、ディスクの空き容量の問題も、

f:id:ts0818:20190317092454p:plain

問題なくなったと... /home/docker 分がリセットされたわけですからね。
まぁ、しかし、kubernetes 関連のファイルは、結局、/ のどこかに配置しないとならない気がするので、/ の容量を大きくしといたほうが良い気がしますね。

 

 

残念ながら、OSがBoot2Dockerのファイルシステムの拡張の仕方の情報が無い...

ネットで調べてみると、一般的な手順としては、

  1. 仮想ディスクのリサイズ
  2. OSに割当て

の手順になるそうです。 

qiita.com

⇧  上記サイト様によりますと、仮想ディスクには「VMDK 形式」、「VDI 形式」 とあるらしく、リサイズ可能なのは、「VDI 形式」であると。

Docker ToolBoxで作成される仮想マシンの元となる、仮想ディスクは、なんと、「VMDK 形式」であると...リサイズできないやん...

f:id:ts0818:20190321170838p:plain

なので、

VMDK 形式 → VDI 形式 → リサイズ → VMDK 形式 → 仮想マシンに設定

という流れになるかと。

「C:\Program Files\Oracle\VirtualBox\VBoxManage.exe」コマンドを使っていく感じですかね。

f:id:ts0818:20190321172046p:plain

Virtual Boxの仮想マシンの一覧を表示で。

VBoxManage list hdds  

f:id:ts0818:20190323132300p:plain

f:id:ts0818:20190323132552p:plain

⇧  defaultっていう名前の仮想マシンは、現状2GBってことですかね。

詳細は、

VBoxManage showhdinfo [仮想マシンのUUID]

f:id:ts0818:20190323132829p:plain

⇧  ディスクサイズが、23MBって...

 

そんでは、リサイズしたい仮想マシンの仮想ディスクのあるディレクトリに移動しておきます。

f:id:ts0818:20190321172241p:plain

んで、仮想ディスクをクローンします、VDI 形式で。

"C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" clonehd [元の仮想ディスク] [変換後の仮想ディスク] --format vdi

f:id:ts0818:20190323131436p:plain

出来上がりました。

f:id:ts0818:20190323131853p:plain

んでは、仮想ディスクのリサイズで。 

"C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" modifyhd --resize [変更後のサイズ] [仮想ディスク]

f:id:ts0818:20190323133321p:plain

仮想ディスクをクローンします、今度はVMDK 形式で。
 

"C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" clonehd [元の仮想ディスク] [変換後の仮想ディスク] --format vmdk

f:id:ts0818:20190323133959p:plain

f:id:ts0818:20190323134342p:plain

仮想マシンの仮想ディスクの情報。VBoxManageコマンドは環境変数にパスが通ってれば、フルパスでなくても実施できましたね。

VBoxManage showvminfo [仮想マシンの名前] | grep ".vmdk"

f:id:ts0818:20190323134818p:plain

変更後の仮想ディスクを仮想マシンに設定。

VBoxManage.exe storageattach [仮想マシンの名前] --storagectl "SATA" --port 0 --device 0 --type hdd --medium [仮想ディスク]

f:id:ts0818:20190323140125p:plain

仮想ディスクが、2つ設定されてる状態?になりました。

f:id:ts0818:20190323140808p:plain

旧い方を解放しようとして、エラー。

f:id:ts0818:20190323141114p:plain

⇧  旧い方の仮想ディスクが仮想マシンに設定された状態になってしまっているから、解放できないってことらしい。

stackoverflow.com

⇧  上記サイト様を参考に、仮想マシンの設定から解除で。

VBoxManage storageattach [仮想マシン名] --storagectl SATA --port [解除したい仮想ディスクのポート] --medium none

f:id:ts0818:20190323145813p:plain

旧い方が、ポート1番を使ってたのが気になるけど...

解放できました。

f:id:ts0818:20190323150449p:plain

ポートの問題なのか、一向にIPアドレスが見つけられない

f:id:ts0818:20190323151741p:plain

致し方ないので、一旦、Ctrl + C で処理を中止し、仮想マシンの電源をOFF、というか結局GUIのほうで操作しとるという...

f:id:ts0818:20190323152333p:plain

んで、ポート1番のほうに仮想ディスクを設定。

f:id:ts0818:20190323152236p:plain

変わらんやんけ~!

 

github.com

In addition, I have gone through the following suggestions and nothing has resolved the issue. The solutions generally involve recreating the VM.

docker/toolbox#457

https://stackoverflow.com/questions/35958619/docker-terminal-waiting-for-an-ip

#3268

#4053

Docker “waiting for an IP” when starting or creating new machine · Issue #4625 · docker/machine · GitHub

⇧  上記サイト様によりますと、解決策は、仮想マシンの再作成をするしかないと... 嘘でしょ...

 

unix.stackovernet.com

⇧  上記サイト様によりますと、VirtualBoxDHCPサーバが問題らしく、仮想マシンを停止した状態で、「VBoxNetDHCP.exe」、「VBoxSVC.exe」のプロセスをKillすれば良いらしい。

Windowsなんで、タスクマネージャーを起動してみたところ、「VBoxNetDHCP.exe」がおったので、「タスク終了(E)」で。

f:id:ts0818:20190330143216p:plain

消えました。

f:id:ts0818:20190330143530p:plain

では、改めて、

f:id:ts0818:20190330144030p:plain

変わらんやんけ~!

すみません、詳細で見たら、「VBoxSVC.exe」もおりました。こやつも消さないといけないようでした。「VirtualBox Interface」が「VBoxSVC.exe」のことやったんですな...知らんがな。

f:id:ts0818:20190330144350p:plain

駄目でした...

qiita.com

⇧  上記サイト様によりますと、仮想マシンのIPが確認できると。

いざ。

VBoxManage guestproperty enumerate [仮想マシン名] | grep IP    

f:id:ts0818:20190330154621p:plain

おんや?IPアドレスが存在しない?

仮想マシンって、IPアドレス無くても動くんだ...

つまり、原因は分からんですが、VirtualBoxDHCPが上手く機能しなくて、仮想マシンIPアドレスが振り分けられないために、「Waiting for an IP...」で止まってしまっていたのであると...

ちなみに、私の環境のVirtualBoxのネットワークは、

f:id:ts0818:20190330160919p:plain

f:id:ts0818:20190330161040p:plain

となっていて、「VirtualBox Host-Only Ethernet Adpter #2」のDHCP サーバーの下限が「192.168.99.100」ってなってると。

そんで、default って名前の仮想マシンが、

f:id:ts0818:20190330161400p:plain

f:id:ts0818:20190330161456p:plain

⇧  「アダプター2」で、「VirtualBox Host-Only Ethernet Adpter #2」を使っていると。

だから、本来なら、IPアドレスとして「192.168.99.100」から順に割り振られるはずなんだけども、それがなされていないと...

 

www.arubeh.com

⇧  上記サイト様によりますと、ネットワークのMacアドレスを更新する必要がありそうです。

更新。

f:id:ts0818:20190330171306p:plain

はい、エラー。

f:id:ts0818:20190330171719p:plain

NATのほうのMACアドレスも更新する必要があったようです。

f:id:ts0818:20190330171842p:plain

でも、結局、DHCPが迷子に...

f:id:ts0818:20190330172541p:plain

 

そして、なんやかんやしてたら、仮想マシンが起動しなくなり申した...

f:id:ts0818:20190330174219p:plain

ja.stackoverflow.com

⇧  上記サイト様を参考に、仮想マシンを再作成で。

f:id:ts0818:20190330174443p:plain

f:id:ts0818:20190330174718p:plain

f:id:ts0818:20190330174806p:plain

f:id:ts0818:20190330174917p:plain

で、通常起動したところ

f:id:ts0818:20190330175949p:plain

f:id:ts0818:20190330175803p:plain

f:id:ts0818:20190330175458p:plain

⇧  なんか、イメージファイルを見つけられないって言ってますな...

 

ja.stackoverflow.com

⇧  上記サイト様によりますと、

考え方としては物理マシンにOSをインストールする時と同じで、インストールメディア(CD/DVD等)をHDDよりも先に参照するよう設定する必要があります。

virtualbox - No bootable medium found! System halted.になる。(virtual box) - スタック・オーバーフロー

⇧  イメージファイルが設定されてないと駄目よってことみたいです。

 

f:id:ts0818:20190330185252p:plain

なんてこった... イメージファイルが設定されとらんと。追加で。

f:id:ts0818:20190330185450p:plain

f:id:ts0818:20190330185603p:plain

f:id:ts0818:20190330185823p:plain

f:id:ts0818:20190330185857p:plain

んで、実行しようとしたらば、

f:id:ts0818:20190330190442p:plain

ん?仮想マシンが存在しないとな?

f:id:ts0818:20190330190734p:plain

f:id:ts0818:20190330190628p:plain

どうやら、クローンすると、VirtualBoxで管理される仮想マシンのほうに含まれるようです。Docker ToolBoxでの管理下にない状態となるため、docker-machine コマンドが使えないと...駄目やん...

なので、default って名前の仮想マシンVirtualBox マネージャーのほうから削除したんだけど、なんかDocker ToolBoxのほうでは残ってるっていう...

f:id:ts0818:20190330191835p:plain

しかも、消せないって...

f:id:ts0818:20190330192127p:plain

 

github.com

For others having this issue, but still can't delete the machine when they add the config.json file:
Check if VBoxHeadless.exe is running (using task manager), this is probably using a file in the machine folder.
Kill it, make sure you have the config.json file and remove ->
Successfully removed default

docker-machine can't remove machine · Issue #3001 · docker/machine · GitHub

⇧  どうやら、プロセスが動いてると。

f:id:ts0818:20190330192923p:plain

んで、config.json ファイルを作成し、

f:id:ts0818:20190330193115p:plain

f:id:ts0818:20190330193236p:plain

いざ。

f:id:ts0818:20190330194209p:plain

⇧  消せないやんけ~!

f:id:ts0818:20190330194427p:plain

⇧  config.json 以外のものがあったのがよろしくなかったのか...。

どうやら、config.json文字コードSJISになってたのが良くなかったみたい...UTF-8で保存しましょう。

もう一回。

f:id:ts0818:20190330194702p:plain

f:id:ts0818:20190330195141p:plain

いけました。

f:id:ts0818:20190330195322p:plain

 

もう一回、default を作り直しで(結局、作り直しになってしまった...それ以外の解決策を知ってる方、教えてください)。

今回は、仮想ディスクの容量を増し増しで。仮想マシン名の綴り間違えた...defualtじゃなくてdefaultが正解でしたね...

docker-machine create --driver virtualbox --virtualbox-disk-size [ディスク容量] [作成したい仮想マシン名]

f:id:ts0818:20190330205127p:plain

f:id:ts0818:20190330205459p:plain

指示通り、コマンドを実行で。

f:id:ts0818:20190330205543p:plain

これまた、指示通りコマンド実行で。

f:id:ts0818:20190330205648p:plain

ようやっと、仮想マシンにログインし直せました。

f:id:ts0818:20190330210403p:plain

f:id:ts0818:20190330213818p:plain

/dev/sda1 のサイズが、17.8G から 29.2G になったんで、全体的なディスク容量は増えてるわけですが、rootパーティションのサイズは変わらず...

 

wiki.ducca.org

qiita.com

go-journey.club

パーティションを拡張するには、LVM(logical volume manager)っていうユーティリティを利用していったほうが良いらしいと。

 

んで、boot2docker には、LVMユーティリティが存在しないと。boot2dockerは、Tiny Core Linux が元になっているので、 

www.markn.org

qiita.com

⇧  上記サイト様によりますと、tce-load コマンドで、LVMユーティリティがインストールできるそうな。

f:id:ts0818:20190330223430p:plain

f:id:ts0818:20190330223734p:plain

はい、エラー。

権限の問題かと思いきや、

f:id:ts0818:20190330224716p:plain

root ユーザーだと実行すらできないと...

 

f:id:ts0818:20190330233844p:plain

tinycorelinux.net

インストールするために他のライブラリが足りないかと思いきや、lvm2 は既にインストールされてるって...『cp: can't stat '/usr/local/share/lvm2/files/69-dm-lvm-metad.rules': No such file or directory』って出とったのが気になるでしょうに...

f:id:ts0818:20190330233630p:plain

f:id:ts0818:20190330233948p:plain

う~ん、ちょっと調査に時間がかかりそうな気がしますね...

解決できてませんが、疲れたので、後日に持ち越しで...。

 

アダプターの種類によるネットワークの違いについては、 

teratail.com

⇧  上記サイト様が詳しいです。 

 

www.lanches.co.jp

⇧  上記サイト様によりますと、VirtualBoxのネットワーク設定には注意が必要のようです。

 

グダグダで、かつ、まったく進展が見られませんでしたが。新たな知見としては、boot2dockerがTiny Core Linuxのパッケージ管理ツールっぽいコマンドが使えるってのを知ったぐらいですかね...まったく成長の兆しが見られない(涙)。

 

2019/3/31(日)追記 ↓ ここから

なんか、Tiny Core Linux ってシャットダウンしちゃうと、インストールしたものがリセットされるらしい...

f:id:ts0818:20190331104120p:plain

 

flac.aki.gs

しかし、まだ安心するのは早いです。
何故ならば、「Tiny Core」は全てがメモリ上で動作していますので、ここでシャットダウン、もしくはリブートをしてしまうと、ここまで頑張って行った設定が全て消えてしまいます。
これが、こういうメモリ上で動作するディストリビューションの厄介なことです。

そこで、シャットダウンしても設定が消えないようにするためのお呪いが必要です。
お呪いのもとは「/opt/.filetool.lst」というファイルです。中味を覗いてみます。

tc@box:~$ less /opt/.filetool.lst

opt
home

となっています。
つまりは、ここに記入されている「opt」と「home」はデフォルトで変更が保存されるのです。
ちなみに、「tce」コマンドでインストールされたソフトは全て「opt」以下で管理されるので、シャットダウンしても消えてなくなることはありません。

TinyCore linuxを試してみる(1)~インストール・SSH接続 – PCオーディオ実験室 

⇧  上記サイト様によりますと、そういうことらしいです。

less /opt/.filetool.lst

f:id:ts0818:20190331104621p:plain

わ~、確かに、「opt」「home」にインストールされたものしか保存されないってなってますね...

less コマンドの終了は、q を押せば良いようです。

qiita.com

f:id:ts0818:20190331105321p:plain

現在のディスク構成の確認。

f:id:ts0818:20190331202007p:plain

また、調べること増えた...

2019/3/31(日)追記 ↑ ここまで

 

今回はこのへんで。 

 

 

NG集

時間の都合上、翌日へ。

Docker ToolBoxで、一度、仮想マシンを作成しておけば、Kitmaticを起動しなくても、VBoxManageの仮想マシンの起動コマンドで動かせるみたい。

f:id:ts0818:20181103132018p:plain

まぁ、仮想マシンsshログインしてみると、

f:id:ts0818:20181103132310p:plain

はい、ダウンロードしていたKubernetesのファイルが根こそぎ消えていると...推測でしかないですが、Dockerの仕様で、「/home/docker」ディレクトリが、Docker起動の度に新しく作り直されるってことですかね?

f:id:ts0818:20181103132404p:plain