kasei_sanのブログ

かせいさんのIT系のおぼえがきです。胡乱の方はnoteとtwitterへ

危機感にかられて今更Dockerを学び直す人の記録(実践編)

Dockerエンジンのインストール

OSXならばこちら → Docker Store

  • 無償のcommunity editionと、有償のenterprise edition がある
  • Dockerは、linuxカーネルの機能を使うので、macwindowsで動かす場合は、小さいLinuxVMを内部で動かしているらしい

色々動かしてみる

こちらを参考に色々やってみた

qiita.com

バージョンの確認

$ docker version

Client:
 Version:      17.09.0-ce
 API version:  1.32
 Go version:   go1.8.3
 Git commit:   afdb6d4
 Built:        Tue Sep 26 22:40:09 2017
 OS/Arch:      darwin/amd64

Server:
 Version:      17.09.0-ce
 API version:  1.32 (minimum version 1.12)
 Go version:   go1.8.3
 Git commit:   afdb6d4
 Built:        Tue Sep 26 22:45:38 2017
 OS/Arch:      linux/amd64
 Experimental: true

Dockerは、クライアント・サーバモデルなので、それぞれの情報が表示される

docker run

新しいコンテナを作成して、起動するコマンド

  • イメージを元に、コンテナを起動する
  • イメージが無い場合、Docker Hub から探してくる

以下は、nginx というイメージを元に webserver というコンテナを起動している

$ docker run -d -p 80:80 --name webserver nginx

Unable to find image 'nginx:latest' locally
latest: Pulling from library/nginx
bc95e04b23c0: Pull complete
f3186e650f4e: Pull complete
9ac7d6621708: Pull complete
Digest: sha256:b81f317384d7388708a498555c28a7cce778a8f291d90021208b3eba3fe74887
Status: Downloaded newer image for nginx:latest
8d291801fd815f6bb8112842c4c1df2d0efd96162d3a28067258502186d3b061

複数のデータレイヤをダウンロードして、イメージを作成している

コマンドの解説

docker run [OPTIONS] IMAGE [COMMAND] [ARG...]
  • -d, --detach: バックグラウンドで実行
  • -p, --publish: ホストマシンとコンテナのポートを接続する。左がホスト
  • --name : コンテナの名前

詳細はこちらも参考

docs.docker.com

docker container ls でコンテナの状況を確認

$ docker container ls

CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                NAMES
8d291801fd81        nginx               "nginx -g 'daemon ..."   22 seconds ago      Up 21 seconds       0.0.0.0:80->80/tcp   webserver

localhost:80 にアクセスしてみる

nginxのデフォルト画面が出力される

$ curl http://localhost:80

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

コンテナ内に入る

docker attach で入れるのは、コンテナがメインのコマンドとしてシェルが起動している場合のみ

適当にぐぐると、 docker attach すると言われる

しかし、docker attach で、コンテナの中をシェルで操作できるのは、メインのコマンドでシェルが起動しているコンテナのみ

今回の nginx イメージは、docker container lsCOMMAND を見ると、メインのコマンドは、nginxをデーモンとして動かしている "nginx -g 'daemon ..."

そのため、docker attach しても、nginxデーモンの標準出力が見えるばかりで、さらにそこから ^D して脱出しようとすると、コンテナが終了してしまう...

docker exec -it 〜 /bin/bash でメインのコマンドがシェルでないコンテナにも入れる

docker exec は、対象のコンテナに任意のコマンドを実行するコマンド

$ docker exec -it webserver /bin/bash
root@7fec1ea5a77b:/# exit

コマンドの解説

docker exec [OPTIONS] CONTAINER COMMAND [ARG...]
  • -i, --interactive: デタッチされるまで標準入力を受け入れるオプション
  • -t, --tty: 仮想端末をコンテナに当てるオプション
    • ちなみに仮想でない端末とは出力を物理的にアウトプットする「テレタイプ端末」のこと

コンテナに対して、インタラクティブな状態で、 /bin/bash を実行している

コンテナの停止

$ docker container stop webserver

停止されたことを確認

$ docker container ls

CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

docker container ls --all で、停止中のコンテナも確認可能

$ docker container ls --all

CONTAINER ID        IMAGE               COMMAND                  CREATED              STATUS                     PORTS               NAMES
8d291801fd81        nginx               "nginx -g 'daemon ..."   About a minute ago   Exited (0) 6 seconds ago                       webserver

コンテナの再開

$ docker container start webserver

コンテナの削除

$ docker container rm webserver

imageの確認

$ docker image ls

REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
nginx               latest              9e7424e5dbae        4 days ago          108MB

imageの削除

$ docker image rm nginx

Untagged: nginx:latest
Untagged: nginx@sha256:b81f317384d7388708a498555c28a7cce778a8f291d90021208b3eba3fe74887
Deleted: sha256:9e7424e5dbaeb9b28fea44d8c75b41ac6104989b49b2464b7cbbed16ceeccfc3
Deleted: sha256:7fcb1f7f8194a8cd7e706d4fc8a0f864cf48bf3937384c4b0a4797af05cc54c6
Deleted: sha256:70a75f17542ef0e6d2686f6ab9f89c22a859c0fe9f9c3abaddb1a893af4f476d
Deleted: sha256:cec7521cdf36a6d4ad8f2e92e41e3ac1b6fa6e05be07fa53cc84a63503bc5700

削除されたことを確認

$ docker image ls

REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE

参考

docker exec を使いこなす – ユニコーンリサーチ

qiita.com

危機感にかられて今更Dockerを学び直す人の記録(概要編)

そもそもDockerって何なの?

コンテナ型仮想化サービス

仮想化サービスとは?

サーバ上に仮想的なサーバを作り出す技術

ホスト型、ハイパーバイザ型、コンテナ型がある

ホスト型

汎用的なOS上に専用のアプリを入れて、仮想化を実現

ハイパーバイザ型

仮想化専用のOSを入れて、その上で仮想化を実現

コンテナ型

独立した環境をOS上に作る技術

他の仮想化技術と違って、別のOSを仮想環境で動かしたり、ハードウェアのエミュレーションをしているわけではない

  • Dockerエンジン

コンテナ型についてもう少し詳しく

コンテナ: 1つのLinuxOS上でリソースを分離、独立させた実行環境のこと

  • linuxに元々ある機能で実現している
    • namespace: プロセス毎のリソースの分離・独立(ファイルツリーなど
    • Cgruops: CPUやメモリ、DiskIOのリソース制限
  • カーネルはホストと共有
  • コンテナは、リソースへのアクセスが制限された、特殊なプロセスとディレクトリの集まり

コンテナ型の利点

  • 開発環境においては、ホスト型より軽量なため扱いが楽
    • 起動が早い、リソースを食わない、ファイルサイズが小さい
  • 最近は、Dockerをそのまま本番環境で動かす仕組みが普及してきたので、本番/開発環境の違いによる問題も解決されるようになった

Dockerとは

Dockerは、アプリケーションの開発、出荷、および実行のためのオープンなプラットフォームです。 Dockerを使用すると、アプリケーションをインフラストラクチャから分離して、迅速にソフトウェアを提供できます。 Dockerを使用すると、アプリケーションを管理するのと同じ方法でインフラストラクチャを管理できます。 Dockerのコードを迅速に出荷、テスト、デプロイするための方法論を活用することで、コードを記述して本番環境で実行するまでの遅延を大幅に短縮することができます。

Docker overview | Docker Documentation

Dockerは、元々コンテナ型仮想化サービスの名称だったが、最近ビジネスが周りだしたので、開発・デプロイ・実行までのエコシステム全体をDockerと言い出した

旧来のコンテナ型仮想化サービスは、Docker エンジン と呼んでいるらしい

Dockerのエコシステム(一部)

  • Docker Hub 等のリポジトリから Docker image(後述) を持ってくる
  • Dockerエンジンは、Docker image を元にコンテナを作成する
  • コンテナの変更を commit すると、新しい Docker image が作られる
  • 新しい Docker image が、リポジトリに push される

Docker image

  • コンテナの元。コンテナを構築するのに必要な情報が格納されている
  • 実態は tar ファイル
  • Docker エンジンはこれを元に、コンテナを起動する
  • イメージレイヤというものの集合体
  • 上記のcommit をすると、イメージレイヤが1毎重ねられる
  • 今までの変更記録が積み重ねられているというイメージっぽい

dockerfile と docker build

元々は、上記のように commit を積み重ねて環境を作る仕組みだった

しかしそれでは、変更箇所を追うことが困難だったので、単純なテキスト形式の設定ファイル(dockerfile)を元に、イメージが作られる機能(docker build)が追加された

参考

デジタルマーケターとWeb担当者のためのGoogle&Yahoo!タグマネージャーの教科書 読書メモ

Chapter1 タグ & タグマネージメント概論

タグ: 外部のサービスを呼び出すためのコード

インターネットのトリプルメディア

  • owned media : 自社メディア
  • paid media : 広告
  • earned media : ソーシャルメディア
    • earn: 稼ぐ、儲ける
    • 信頼や評判を稼ぐメディア

ターゲティング: ユーザの行動によってコンテンツを変える手法

マーケティング

  • 再訪を促すために外部のサイトに広告を露出する機能
  • それの為に必要なタグ → リマーケティングタグ

動的リマーケティング(データフィード広告)

  • 離脱前の深度や購入しようとした商品によって、表示を切り替える広告
  • サービスの情報を事前に広告ネットワークに提供(フィードしておく)ので「データフィード広告」

DMP(Data Management Platform)

  • 行動履歴から、ユーザを分類
  • セグメントに応じて広告を表示する
  • オーディエンス拡張
    • 購買したユーザに行動履歴が似ているユーザに広告を表示する

タグの複雑化によって起きる課題

  • 効果的な広告のために複数のタグをサイトに埋める必要がある
    • 行動分析用、広告表示用、レコメンド用...
    • 変更・追加の度にHTMLの修正が必要
      • サイトによっては開発者に依頼する必要がある
      • 開発者が外注や他部署だとたいへん
    • 複数ページにタグを埋めると、漏れが発生したりする
      • テスト書けよ or 共通化しろよと思う
    • javascriptエラー発生時の影響
      • これって、タグマネジャーだと解決するものなの?

そこでタグマネージメントですよ

  • ワンタグ → 外部のjavascriptコードを呼び出すためのjavascript
  • コンテナ方式
    • 1つのコンテナから、複数のタグを呼び出す
    • ページ毎に異なるタグを呼ぶのはできない
  • クライアント方式
    • タグマネージャーサーバから、必要なタグをページや条件毎に出力
    • ページ毎の変数、ユーザのアクションなど
    • エラー検知(GTMのエラー検知方法を知らない
    • タグのバージョン管理
    • 動作検証

タグマネージメントの未来

ここまでの感想

  • タグマネージャーって突き詰めると、広告やアクセス解析者といったマーケティングの人とエンジニアが乖離したために生まれた「妥協の産物」のような気もしないでもない
  • けど、エンジニアからの分離って進歩と捉えても良いことだよね
  • 「タグマネージャーを使って、手でタグを埋める時代」は早晩終わりそうな気もする
  • あと、オープンなwebと広告文化の相性の悪さが気になってしょうがない
    • webの未来を決める人と、広告文化はケンカの歴史とも思える
  • どうなっていくんでしょうね

Chapter2 「Googleタグマネージャ」の導入と活用

TODO.

Chapter3 「Yahoo! タグマネージャ」の導入と活用

YTMを使う予定がないので割愛

Chapter4 タグマネジメントツールの導入と活用

TODO.

Chapter5 タグマネージメントにおいて便利なツールとノウハウ

だいたい知っていた

ビーコン: タグによって送信されるHTTPリクエス

requestb.in

https://requestb.in/requestb.in

エンドポイントを作成して、どのようなリクエストが来ているかチェックするサービス APIのテストや動作確認に使う用途らしい

WASP.inspector

chrome.google.com

ページが、どんな外部jsを呼び出しているか一覧できるChrome機能拡張

Appendix タグを支える技術

基礎的なHTTP、HTML、css、jsの解説

週報 2017/11/20週 読書感想会の結果をまとめた週

期間

2017/11/20(月) 〜 2017/11/26(日)

今週やったこと

インプット

なし

アウトプット

developer.feedforce.jp

同人活動

kakuyomu.jp

  • 文章は苦手だと思っていたけど、こういう形式ならばサクサク書けることに気がついた

  • 冬コミでコピー本追加
  • なるべく低コストで作成することを目指してみる

KPT

Keep

  • 読書感想会のことアウトプットできてよかった
    • 引き続き、12月も実施したい

Problem

キャリアに関する不安が取れない

自分に足りないと思っていることを各個撃破するしかない

  • Docker, 英語力

Try

  • GTM本おぼえがきアウトプット
  • 仕事でチームを再編成しているので、その時やったこと、心がけたことを記録しておく
  • Dockerについて、最低1つアウトプットする

週報 2017/11/12週 主にHMC5の準備

今週やったこと

インプット

デジタルマーケターとWeb担当者のためのGoogle&Yahoo!タグマネージャーの教科書

デジタルマーケターとWeb担当者のためのGoogle&Yahoo!タグマネージャーの教科書

  • 職場のチームの勉強会資料
  • 1章まで読んでまとめた

Rails Developers Meetup

  • 参加

テスト駆動開発

テスト駆動開発

  • 社内読書感想会実施

アウトプット

HMC5 -踊るニンジャ学会- - MOGRA 秋葉原

  • ご好評いただけて本当によかった

KPT

Keep

  • 仕事以外の自分の興味のインプット/アウトプットだいじ
    • そういう所から仕事へのヒントも生まれる
  • 社内読書感想良かった
    • 普通に読むより多くの知見が得られる

Problem

  • インプットした結果のアウトプットが滞っている
    • サクサクやる方法を手に入れたい

Try

  • アウトプット

週報 2017/11/05週 さっそく1回飛ばしました

今週やったこと

インプット

テスト駆動開発

テスト駆動開発

  • 引き続き読書中。来週社内で読書感想会をやる予定

その幸運は偶然ではないんです!

その幸運は偶然ではないんです!

  • だいたい読んだ。なんというか「こういう考え方もあるよ!」くらいの割と軽い本だった

アウトプット

第一回FFLTでCSVについて話してきた

LT資料

KPT

Keep

  • LT良かった。刺激を受ける

Problem

  • 運動不足。精神的に影響を受けるので定期的に運動したい

Try

  • 週1で筋トレに行く
  • TDD本の感想blogにまとめる

第一回FFLTでCSVについて話してきた

FFLT って何よ

エンジニアの情報発信や交流を深めるために、feedforce Lightning Talks (FFLT) を開催します!:tada:

弊社内のエンジニア同士でLT大会して、情報発信力をつけたり、他チームの知見を取り入れたり、交流したりしようぜ! という会でした

参加した感想

主催メンバーの やったことに価値がある。結果は大事だが、そもそも打席に立ってバットを振らないとヒットもホームランも出ない と言う言葉に大変感銘を受けました

最近「ブランド・ハップンスタンス理論」の本を読んでいまして、 それは キャリアの機転の8割は計画したものでは無く、運や偶然に左右されるもの と捉えて、その運や偶然を拾うために、とにかく色んな偶然が起こるように色んなチャレンジをしてみようぜ! という思想なのですが、とにかく「打席に立たないとヒットもホームランも出ないよね」という主催メンバーの話も似た話だなぁと感じました

その幸運は偶然ではないんです!

その幸運は偶然ではないんです!

↑タイトルがインチキ啓発本っぽいのがアレですが、まあまあ面白かったです

はっぴょう資料

CSVRFCみんな読んでね! というお話をしました

頂いた感想

パンチカードについては、CSVと別に以下のお話をしました

  • ascii の 0x7F は、パンチカードで「この列は間違えたので、全部穴を明けて消した」を意味する文字コード

TRY

CSVのパースは OCaml だと効率良く出来そう。というお話を頂いたので、少し見てみることにします

参考資料

CSVRFC

CSVファイルの一般的書式 (RFC4180 日本語訳) - アルプス登山の玄関口・笠井家

最後のおまけで話した、CSV の liberal_parsingオプションと、不具合について

ruby 2.4.0 CSV の liberal_parsing オプションについて調査してみた - Qiita

LTで少し話した、rubyのCSVLibraryと、splitした場合の速度比較について

いじょうです

そんな感じでした! FFLT立ち上げ、実行メンバーの皆さん本当にありがとうございました!

次回は何を話そうかな...