「みんなの翻訳」は、世界中の文書をみんなで協力して翻訳するサイトです。

みんなの翻訳ロゴ
ブクタブ
翻訳サイト

カテゴリ一覧

このサイトについて 新規登録はこちら お試し翻訳

一覧

2017/07/28

メンテナンス終了のお知らせ

2017/7/25-2017/7/28に実施したメンテナンスは、2017/7/28/14:20に終了いたしました。 ご協力をいただき、ありが…

List

Hnoss

English⇒Japanese

shikimi

English⇒Japanese

sysInfo

English⇒Japanese

tkkobe

English⇒Japanese

ホーム > 翻訳記事

翻訳記事

Dockerビギナーズガイド | from Opensource.com / Vincent Batts

2014年 8月 19日 Vincent Batts 
イメージ画像: opensource.com (cc-by-sa)

  これから作ろうとしているアプリが、芸術的に的確な精度を持ったお仕事用なのか、それとも単なるオモチャなのかに関係なく、コンテナはその製造と転送に関するしっかりとした方式を提供する。
  まるで、運搬用コンテナを出荷するような感覚で、作成したアプリケーションの取り込みはき出しができるようになった革命的なこの方式を、みんな「Docker」という形式では知っているよね。

  コンテナという方式は、使い道がはっきりしていることと、その使い方がいろいろな人のニーズに合っててその上簡単だから、人気が飛び火したと言える。

 

  Dockerを理解する

  コンテナは開発から管理までを一貫した方式で、効率よく行うための手法だ。
  Dockerには、コンテナを使ううえでのプロセス(PIDs)をさらに細分化する役割があり、メモリ、CPU、ネットワーク・アクセス、ディスクアクセスを管理できる。これでアプリケーションを動かすのに必要な要素はすべて網羅されている。
  このようにして、アプリケーション運営に十分な環境を構築するのが、Dockerの使用目的だ。

  Dockerの中には、詳細な実行ファイル、ライブラリ、標準Cライブラリ(libc)が入っている。
  もちろん、カーネルも入っているけど、それはたくさんの構成パーツを動作させるだけではなく、PIDsにどのリソースを使わせるかを指令したり、libcから必要な情報を要約したりする役目がある。
 

  とにかく、DockerにはPIDsを設定管理するための様々な環境が揃っている。

  たとえば、別バージョンのlibcを使いたいときには、root (chroot)権限で変更するのは案外普通の使い方だし、メモリーを制約する必要がある時に、カーネル・コントロールグループ(cgroups)を使えば、細かい調整ができる。

  こんな設定を仮想マシン(VM)で行うには、ハイパーバイザーにランタイムを完全形で封じ込めて、一度システム全部を初期化/再起動しなくちゃ使えなかった。

  でも、PIDsに求められるものは、命令やタスクだけ。実際使ってみると、VMがどれだけ無駄にリソースを消費しているのかがわかる。

  Dockerに切り替えれば、root権が使えるようになる。つまり、cgroups、アイソレーション、ルートファイルシステムの共有が簡単にできるようになる。ファイルシステムを計画的に設計しなおすことも可能というわけだ。

 

  それでは、Dockerの来歴を簡単に説明しよう。
  まず、Dotcloud, Inc.という団体が、2013年1月にプロジェクトを開始して、同じ年の3月に公表したものが、最初のバージョンだった。

 この団体はDockerの制作にかかる以前、platform-as-a-service (PaaS)の開発に注力していた。「PaaS環境をどこでも構築できるようにならないか」というのが、Docker開発の動機だったらしい。

  Dockerが公開されてからというもの、GitHubページは、炎上というべきか、盛り上がっているというべきか、ともかく大人気だった。

 たったの1年で500以上の寄付者と、10近くの開発団体を抱えるようになった。70以上のリリースで、スター数は13, 000+、フォークは2, 000+、駆け出しのオープンソース・プロジェクトがこんなにも大きくなるなんてことは、これもある種の社会現象じゃないだろうか。

  そして、2014年6月、ついこの間のことだけど、Dockerは動作の安定性とlinux-amd64コンテナでアプリケーションを制作できるようになったとして、バージョン1.0.0を発表した。
 

  Dockerを注視していた開発者やシステム管理者たちは、直接やりとりができないか試みた。開発者と管理者たちが、問題意識を当たり前のように共有するためだ。

 

  開発者が抱えている問題

  • ビルドの度に開発環境に矛盾がないか注意する必要があること
  • 各自が記述したコードを他の人もわかるように文章化すること
  • 必要なソフトウェアをホストバージョンとぶつかり合わないようにインストールするには、どうすべきか
  • 環境が確実なものになるようテストすること
  • 説明可能なデータと、過去にさかのぼって調査ができるストレージの作り方
 システム管理者が抱えている問題
  • ソフトウェアを監視できるようにするための完全な証明書を作成すること
  • プロセスに干渉し、リソースを割り当てる方法
  • アプリに求められるネットワーク構成の方法
  • 説明可能なデータと過去にさかのぼって調査ができるストレージの作り方

  ちゃんとしたイメージ・フォーマットさえできれば、開発者はすべてのサーバーを同じように管理できるし、管理者もすべてのコンテナをコンテナを同じように見ることができる。

 そして、両者が抱えている問題は、Dockerのディレクトリアドレスをどのように管理するかということだった。

  まず、Docker環境における「イメージ」と「コンテナ」の使い方をはっきりさせる必要があった。 
 

  [イメージ]

 ポータブル:この方式は、レジストリやtarアーカイブとして保存されたデータを圧迫する可能性がある。

 レイヤード:この方式はイメージが具体化されるにつれ、必要と判断されたため追加された。それぞれのイメージを制作する方式はおおよそ同じではあるが、最終的にはいくつかの分岐点を与えることで、それぞれの違いを出す。同じ部分を共有することで、使用するディスク量を減らすことができる。

 安定性:新たにイメージを作り出さないかぎりは、コンテンツに変更を加えられないようにしたほうがよい。
 

  [コンテナ]

 ランタイム:PIDsを行うための環境

 書き込み可能:一時ストレージが必要

 レイヤード:[イメージ]と同じ

  これらの課題が背景となって、たくさんの開発が行われた。その結果が、現在のDockerの基礎や機能性につながっていった。


 

  基本的な使い方

$> docker run busybox echo 'Hello, World!'
Hello, World!

 はい。これがHello, World!の出し方です。
  まず、Dockerでコマンドを出そうと思ったら、「run」で「busybox」イメージを起動させる。

  たとえ、『busybox』イメージが記述されていなかったとしても、Dockerが「public Docker hub」から『busybox』イメージをなんとか引き出すから、大丈夫だろうけどね。
 


  それでは、Dockerのレイヤーを設定する方法を説明しよう。ここで、コンテナ環境で使われるすべてのcgroupsやnamespacesを設定して、『echo 'Hello, World!'』を実行する。
 


    $> docker pull fedora

 

 これが、Dockerにpublic Docker hubから、『fedora』という名前のイメージを呼び起こすやり方だ。
 



    $> docker images

 

 これで、ローカルでも使えるイメージが表示される。このように、「docker」の後にはさまざまなコマンドを入力できる。使用可能なコマンドを見るには、『docker help』と入力すること。

 

 Docerイメージは対話しながら運用することが可能だし、この先使う予定のコンテナ・イメージを後で実行するタイミングを指定することもできる。


 

    $> $ docker run fedora touch file
    $> docker ps -l
    CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS                     PORTS               NAMES
    9626763a35f9        fedora:20           touch file          6 seconds ago       Exited (0) 3 seconds ago                       prickly_goldstine
    $> docker commit 9626763a35f9 my-touched-file
    $> docker run my-touched-file ls -s /file
    0 /file


 

新しいイメージを実行するには、「Dockerfile」フォーマットを使う。「Dockerfile」とは、イメージを使う準備段階で使われるファイルだ。
大まかにいうと、これには小さなメタデータが入っていて、それがLinuxでいうところのシェルスクリプトに相当する。
 


    FROM fedora
    RUN yum install -y mongodb-server && mkdir -p /data/db
    EXPOSE 27017
    VOLUME ["/data/db"]
    CMD mongod


 

 『fedora』イメージをビルドできたら、次はシェルコマンド使って、ソフトウェアをインストールして、ディレクトリを作成する。
 

  公開するポートや、データを保管するためのディレクトリを決定するのはそれからだ。


  それらの作業を経て、最後にコンテナのランタイムを実行するコマンドを宣言する。(例:mongod)

 

こうして作り上げた「Dockerfile」を起動するには、次のように命令する:
 


    $> docker build -t mongodb

 

以上の工程で、『mongodb』イメージが使えるようになる。

 

これからサービス・コンテナを運用する時には、『mongodb』イメージをDockerfileでビルドして使うこと。サービスを停止させたり見直すときには、このファイルを当たってほしい。
 




    $> docker run -it -p 127.0.0.1:27017:27017 -v $(pwd)/db:/data/db mongodb

 

このコマンドで『mongodb』サーバーが起動する。それには事前割振りファイルが必要だ。



それでは、runの後に続いているフラグたちについて説明しよう。
 

  • 『-it』はターミナルの接続を意味する。<ctrl>+c でプロセスを中断できる。
  • 『-p 127.0.0.1:27017:27017』は、「処理すべきポート(-p)は、127.0.0.1:27017コンテナに配属されている27017番ポートです」という意味。
  • 『-v $(pwd)/db:/data/db』で、「/data/db'ボリューム(-v)を、ホスト側の$(pwd)/dbにマウントしなさい」という意味。

 

こうしてmongodbを動かしてみているけれど、ターミナルではどのように表示されているのだろう。見てみよう。
 

    $> docker ps
    CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS                      NAMES
    cb5346e10a69        mongodb:latest      /bin/sh -c mongod   2 minutes ago       Up 2 minutes        127.0.0.1:27017->27017/tcp   hopeful_torvalds    

コンテナのランタイム『mongodb』の情報がきちんと表示された。  プロセスを終了させるには、さっき紹介した <ctrl>+c がオーソドックスだ。でも、『docker kill cb5346e10a69』でも可能だから、それは頭の隅に置いといて。

 

  コンテナで発生した一時データは、ホストディレクトリにマウントされた、「/data/db」ディレクトリに収容される。データはコンテナが再起動したときは、再利用されるようになっているけれど、『docker run』で起動した場合にはすべて消去される。
 

 ローカル共有 
 

Dockerイメージのpublicディレクトリは、Docker hubにある。これにはローカルDockerイメージのホストを許可する機能がある。

  多くのLinuxディストリビューションがdocker-registryをパッケージングしているくらいなので、Dockerレジストリを使うこと自体も簡単だ。

    $> docker run -d -p 5000:5000 -v $(pwd)/registry-data:/tmp registry:latest


これでDockerイメージをローカスサービスとして使うことができるようになった。

  サービスを開始する前に、ホストから「0.0.0.0」の設定をきかれるだろうけれど、これはホストのIPアドレスか、DNS名でタグ付けすればよい。

  ただ、おすすめはDNS名だ。IPアドレスが変更された時に、ローカルDockerイメージにもう一度タグ付けする必要がなくなる。
 

ローカル・レジストリを使うには、イメージに「イメージ名」をつけなくてはならない。

 これは『docker build』の際に設定できるほか、次のようにタグ付けすることができる。

  DNS名を「image-storage.local.lan」と仮定すると(この部分は完全に個人の裁量で決めていただきたい)、ホストのIPアドレスが指定される。

次のように設定する:

    $> docker tag mongodb image-storage.local.lan:5000/mongodb
    $> docker push image-storage.local.lan:5000/mongodb


ローカルネットワークに存在する他のDockerに限らず、新しくタグ名をつけるときには、このイメージが参考になる。

 

 開発環境を確実なものに 

たくさんのDocerの使用説明書が、サービスの作り方やスケールの方法については述べているのだけれど、開発方法をより信頼できる、堅牢なものにする方法についてはあまり言及されていない。

 Dockerイメージは、古風なコードから今時のコード、それから現在も開発中の最先端のコードを使って、開発環境を構築することができる。 

 VMハイパーバイザーの場合、その辺の心配には及ばない。というのも、ネットワーク・アクセスの段階で「常に正しいバージョンで、マシンをビルドする」のだそうだから。( "the build machine with the right versions of everything")
 

  さらに、Dockerの開発環境はひとたび構築されると、ローカルレジストリで共有する準備もできている。

 これでDockerを動かせるマシンならどれでも、イメージを運用できるようになるし、ワークステーションを作れるようになる。

  前の章では、Dockerfileを設定することで、ベースイメージを分類できるようになることを説明した。

 それでは、最終段階としてユーザーネームを個別設定する方法を紹介しよう。

fedora:20の場合、
     
# セットアップやインストールを終えた後
    RUN yum groupinstall -y "Development tools"
    RUN yum install -y vim-enhanced git
    CMD bash -l
     
# 以下の部分がユーザーごとに異なる
    RUN useradd -m -u 1000 vbatts
    ENV HOME /home/vbatts
    WORKDIR /home/vbatts
    USER vbatts

これをビルドしたら、タグ付けしてローカルレジストリに保管。

    $> docker build -t image-storage.local.lan:5000/$USER/devel:f20 .
    [...]
    $> docker push image-storage.local.lan:5000/$USER/devel:f20

さて、次はユーザーネーム設定をきちんとビルドしなくてはならないのだけど、それには、下の開発イメージを使う。これは、シェルがアクティブでも、開発イメージが安定するよう、ソースとホームディレクトリはそのままにホストするという設定だ。

    function devel() {
        docker run \
        --rm \
        -it \
        --hostname=$(hostname)-devel \
        -v $HOME:$HOME \
        -v $SSH_AUTH_SOCK:$SSH_AUTH_SOCK \
        --env SSH_AUTH_SOCK \
        --env PATH=/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin \
        --workdir $(pwd) \
        ${1+"$@"} \
        image-storage.local.lan:5000/$USER/devel:f20
    }
 

この設定ファイルは、『~/.bashrc』用bash関数で構成されている。『devel』と呼ばれる関数を定義する働きがあり、開発イメージをビルドする時に実行される。それでは『docker run』の後に続くフラグを説明する:

  • 『--rm』シェルが実行された後にコンテナを消去する働きがある。
  • 『-it』対話式の付属ターミナルを作成する
  • 『--hostname=$(hostname)-devel』コンテナ内のホストネームを設定する。ただし、『devel』の部分はホストネームとは扱われない。
  • 『-v $HOME:$HOME』同じコンテナの内部に、常にホームディレクトリをマウントさせる
  • 『-v $SSH_AUTH_SOCK:$SSH_AUTH_SOCK』コンテナ内部に「アクティブsshエージェント・ソケット」をマウントさせる
  • 『--env SSH_AUTH_SOCK』sshエージェント環境変数を通過する
  • 『--env PATH=...』PATH履歴を消去する
  • 『--workdir $(pwd)』常に動作しているディレクトリ(例: ~/src/my/big/project/)に入ると、bashシェルを開始する。
  • 『${1+"$@"}』関数に『devel』フラグを追加させる

 

    vbatts@noyee ~ $> cd src/my/big/project
    vbatts@noyee ~/src/my/big/project

    $> devel
    vbatts@noyee-devel ~/src/my/big/project $> make
    [...]

これはホストを混乱させずに、プロジェクトに必要とされるだけのライブラリと、ツールとをシームレスにつなぐ設定だ。


 CI / Testing 

継続的インテグレーション(CI)を使って、ソフトウェアのビルドとテストを行える。Dockerfileのビルドは、シングルアクションの中にCIをラップさせられる。これがうまくいくと、幾分か手間が省ける。

    [...]
    RUN cd /src/myapp && git pull --force origin master && \
     autoreconf && \
     ./configure && \
     make
    RUN cd /src/myapp && \
     make test

 Dockerfileが閉じられるときには、イメージファイルがビルドされるようになっている。

 さらに、ベースイメージからDockerfileをビルドするか、環境をカスタマイズすることで、ビルドの際にホストを共有したり、バージョンに矛盾で生じる問題や、コンパイルしなくてはならない物の数を軽減できることがある。

Dockerの基本的な使い方は以上。

これらを応用すれば様々な使い方に対応できる。

開発→制作のサイクルをスタートさせるのは別に難しいことではないことがわかったかな。ローレベルなビルドを調整すると同時に、プログラム環境を編成することもできる。

基本がわかったら、コンテナについての情報を交換しあって、Dockerの成長につなげよう。

PDF
更新日:2017-06-22 00:09:25 Hnoss 0  del.icio.usに追加   はてなブックマークに追加   twitterに投稿   facebookでshare
公開ノート

今回は翻訳ツールがきちんと動かなかったので、少し大変でした。

[ 原文 ] https://opensource.com/business/14/7/guide-docker Creative Commons License この作品は、クリエイティブ・コモンズ・ライセンスの下でライセンスされています。
クリエイティブ・コモンズ・ライセンス
翻訳者ページをみる

この記事の翻訳者

Hnoss さんの翻訳記事

【GitLab 公式 を訳してみた】ランナーを登録する

GitLab Runner > ランナーを登録する  「ランナーの登録」とは、GitLabで実際に使っていくランナーをまとめあげる工程を指します。   前提条件   ラン…2017-11-24 21:17:38

【GitLab 公式 を訳してみた】GitLab Runnerをインストールする

GitLab Runner >Install GitLab Runner  GitLab Runnerは、GNU/Linux、 macOS、 FreeBSD、 Windowsでインストールと使用することが可能です。  インストールには3つの方法があり…2017-11-24 21:16:30

【GitLab 公式 を訳してみた】GitLab CI~コードの質を「Code Climate CLI」に判定してもらう設定

GitLab Documentation > GitLab Continuous Integration (GitLab CI) > GitLab CI 設定サンプル集 >コードの質を「Code Climate CLI」に判定してもらう  開発しているアプリ…2017-11-24 19:27:43

【GitLab 公式 を訳してみた】 .gitlab-ci.yml 設定メニュー

 (訳者より:翻訳がもうだいぶ進んだところで、GitLab CIについてネットで検索をかけてみたところ、 Qiitaにてynott様が公開されたバージョン があることに気がつきました。  原…2017-11-24 19:21:10