docker-compose でよく使いそうなコマンドおぼえがき

ビルド

docker-compose build # Build or rebuild services

起動、停止

docker-compose up      # Create and start containers
docker-compose up -d   # デーモンとして起動

docker-compose start   # サービスを開始
docker-compose restart # サービスを再起動
docker-compose stop    # サービスをstop
docker-compose kill    # サービスを強制終了

コマンド実行

# 起動中のコンテナでコマンド実行
docker-compose exec ${service_name} ${command}

# コンテナを作成してコマンド実行(実行後コンテナを削除
docker-compose run --rm ${service_name} ${command} 

削除

# Stop and remove containers, networks
docker-compose down

# imageも削除
docker-compose down --rmi all

# 名前付きvolume も削除 
docker-compose rm  --volumes

一覧

docker-compose images               # image の一覧
docker-compose ps                   # 起動しているコンテナの一覧
docker-compose top ${service_name}  # サービスで実行中のプロセスの一覧
docker-compose logs ${service_name} # View output from containers

Alpine Linuxで素のRailsが動くDockerfile を作った

DBはPostgreSQLで、他に余分なgemを入れなければこんな感じ

FROM ruby:2.5.0-alpine

COPY Gemfile* /myapp/
WORKDIR /myapp

RUN apk upgrade --no-cache && \
    apk add --update --no-cache \
      postgresql-client \
      nodejs \
      tzdata && \
    apk add --update --no-cache --virtual=build-dependencies \
      build-base \
      curl-dev \
      linux-headers \
      libxml2-dev \
      libxslt-dev \
      postgresql-dev \
      ruby-dev \
      yaml-dev \
      zlib-dev && \
    gem install bundler && \
    bundle install -j4 && \
    apk del build-dependencies

COPY . /myapp

ポイント

• --virtual を使うことで、bundle install にしか必要のないLibraryは、あとでまとめて削除してサイズを節約(100MBくらい違う)
• gem install bundler は、ruby:2.5.0-alpine の中でもやっているけど、もっかい実行して最新のものを取得している

Alpine Linux とは?

組み込み用の超軽量ディストリビューション BusyBox をベースに、パッケージ管理ツール等をのせたものらしい

何が良いの?

Imageのサイズが軽い。とにかく軽い。単品のImageが5MBとか。

Imageが軽いと何が良いの?

生産性があがる

• CIやデプロイ、開発環境作成時等、Imageをデプロイするタイミングでの待ち時間が減る
• Imageのダウンロード/アップロードも待ち時間が減る

実際どのくらい違うの?

ruby 2.4.2 alpine と、ruby 2.4.2 でこれくらい違う

REPOSITORY            TAG                 IMAGE ID            CREATED             SIZE
ruby                  2.4.2-alpine        3bc1f3c1b02b        3 months ago        63.4MB
ruby                  2.4.2               5dce8a4be4f6        3 months ago        687MB

時代は alpine なの?

Docker公式のImageも Alpine Linuxだし割りとそんな感じ

ただ、コマンドも最低限だし、gemのインストールに必要なパッケージも色々手で入れる必要があるので、Dockerがあんまりわかんないうちは使わないほうが良いかも

おまけ

docker-compose.yml はこんな感じ

version: '3'
services:
  db:
    image: postgres:10-alpine
    volumes:
      - db_data:/var/lib/postgresql/data
  web:
    build: .
    command: bundle exec rails s -p 3000 -b '0.0.0.0'
    volumes:
      - .:/myapp:cached
      - bundle_data:/usr/local/bundle
    ports:
      - "3000:3000"
    depends_on:
      - db

volumes:
  db_data:
  bundle_data:

fluent-plugin-slack では、仕様上リンクテキストの修飾は使えないよというお話

先に結論

fluent-plugin-slack では、仕様上slack のテキストリンク修飾は使えないので諦める

(こんな風にそのまま出力される)

詳細

• <>& はエスケープされて出力されるように実装されている
• そのため <example.com|example> もエスケープされてそのまま出力される
• issue は上がってるけど 2016/04 より放置されているので修正は期待できない
  • まぁどう修正するの? って話しではあるけれど...

感想

もし修正するならば、オプション(unescapeとか)を追加して、エスケープの可否を設定するとかが良いのかな...

危機感にかられて今更Dockerを学び直す人の記録(data volumeをおさらい)

今日やること

data volume を理解し直す

data volume ってなんぞ

ボリュームは、Dockerコンテナによって生成され、使用されるデータを永続化するための推奨されるメカニズムです

docs.docker.com

Dockerコンテナの中のファイル/ディレクトリは、コンテナが終了すると削除されてしまう

そのため、永続化したいデータがあるときに、data volume を使う

data volume は、ホストのファイルシステムに作成されるディレクトリで、コンテナにマウントされる (普通は /var/lib/docker に生成されるらしい)

また、特定のホストのディレクトリと紐付けることも可能で、その場合、ホストの特定のディレクトリをコンテナから参照できる (開発環境では主にこの使い方をするはず)

data volume は、起動時の --volume (-v) オプションもしくは --mount オプションで指定する

--volume (-v) オプション

値は、: で区切られた3つの値を指定する

• 1個目 : ホストマシン上でのpath。もしくは、名前付きボリュームを指定。省略すると匿名ボリュームになる
• 2個目 : コンテナ上でのpath
• 3個目 : オプション(カンマ区切り。後述)

ボリュームは、ホストマシンの特定のディレクトリと紐付かなくても作成できる

-v オプションで、: 区切りの1個目を指定しない場合、無名のボリュームが生成される。これを匿名ボリューム(anonymous volume)と呼ぶ

使いそうなオプション

• ro: 読み取り専用(read-only)
• cached: コンテナからの読込速度が早くなるかわりに、ホストの更新がコンテナに反映される場合に遅延が許可される
• delegated: コンテナからの書込速度が早くなる代わりに、コンテナの更新がホストに反映される場合に遅延が許可される

cachedと、delegatedは、Docker For Mac でのディスクIOが遅いという問題を解決できると公式ドキュメントに書かれてた

docs.docker.com

--mount オプション

key=value形式で、マウント方法を指定するオプション

type=volume で、ボリュームの設定もできるらしいけど、普段あんまり使わなそうなので割愛

data volume の一覧を見る方法

$ docker volume ls

ローカルのdata volume の格納先を確認する方法

$ docker volume inspect #{volume name}

Mountpoint にpathが書かれている

Docker for mac の場合、書かれているpathは、dockerが動作しているVM上のpathなので、VMにsshする必要がある

$ screen ~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/tty

感想

前回書いた、dockerでrailsを動かす記事の、volumeの設定に誤りがあることを理解した

以下はdata volumeにした方が良い

• データベースのデータが格納されるディレクトリ
• アプリサーバの gem が格納されるディレクトリ

kasei-san.hatenablog.com

参考

developer.feedforce.jp

• 弊社記事。ここに書かれていることと、自分の記事の差異から、この記事が生まれた。感謝!

docs.docker.com

• 公式ドキュメント

https://success.docker.com/article/Different_Types_of_Volumessuccess.docker.com

• 公式。data volume の違いについて説明している

合格対策 AWS認定ソリューションアーキテクト(アソシエイト) の読書メモ 1〜5章

試験対策本を読んで、知らなかったことや曖昧だったところをメモ

合格対策 AWS認定ソリューションアーキテクト - アソシエイト

はじめに

Design for Failure(障害に耐えうる設計) という思想

• 単一障害点の排除
• 全てが故障すると仮定して保守的に設計する
• 疎結合なシステムの構築

参考になりそうなスライド

AWSを用いた耐障害性の高いアプリケーションの設計 from SORACOM, INC

www.slideshare.net

1章: AWSと認定プログラム

AWS7つのベストプラクティス

1. アプリケーションとSaaSプラットフォームの分離
2. 機能は抽象化してサービス化する
3. マルチテナントで構成する
4. データのライフサイクルを把握する
5. 全ての情報を収集してそこから学ぶ
6. コストと性能の最適化を行う
7. 高セキュリティと分離を意識する

解説スライド

資格について

• 資格の期限は2年。再試験orランクアップ
• 合格ラインは非公表

2章: リージョン/アベイラビリティーゾーンとAWSサービス

ELBはAZ間の負荷分散のみ。リージョンを跨ぎたければRoute53を使う

3章: 責任分担セキュリティモデルとAWSによる認証(IAM)

• IAMロール: EC2に権限を付与する
• ID federation: 社内の認証基盤とIAMを連携できる

責任分担セキュリティモデル

サービス毎にAWSとユーザでセキュリティの責任を分担する

4章: AWSにおけるネットワーク(VPC)

TODO: 良く分からんかったので、実際にいじって確認する

VPCは最上段のプライベートネットワークで、VPCの中に作るのがサブネット。機能毎にサブネットを作るのが理想的。

参考↓ qiita.com

• サブネットはAZを跨がない
• バーチャルプライベートゲートウェイ: 専用線でオンプレと繋ぐためのゲートウェイ
• パブリックサブネット: インターネットへの接続を許可
• プライベートサブネット: インターネットへの接続は不許可

5章: AWSにおけるコンピューティング(EC2/AMI/EBS/インスタンスストア)

• インスタンスタイプのアルファベットの後の数字はそのインスタンスタイプの世代 (t2なら2世代目)
• ユーザーデータ: 初回起動時に実行したい処理を設定

EBSとインスタンスストア

• EBS: 不揮発
• インスタンスストア: 揮発性
• EBS backed: EBSにOSをインストールする
  • 停止、再開、再起動、削除
• Instance Store-Backed: インスタンスストアにOSをインストールする
  • 再起動と削除のみ

EBSスナップショット

• ディスクIOを止めてからやる。アンマウントするのがセオリー。
• スナップショットの取得を開始したら、IOが発生しても良い
• EBSはAZをまたげないので、EBSスナップショットをつかって移動する

プレイスメントグループ

単一AZ内の低レイテンシグループ(クラスタ)や同一ハードウェアに複数EC2インスタンスを生成して、冗長性を犠牲にネットワークを高速化する

docs.aws.amazon.com

dedicatedインスタンス

物理ホストに他のアカウントのインスタンスを起動しないことを保証するサービス

aws.amazon.com

家で作業と家事を同時にこなす「家事ポモドーロ・テクニック」がとても良かったので布教します

家で作業をすると、ついその前に部屋を片付けてしまったり、周りにある誘惑に負けて、全然作業が進まないことありませんか?

そんなときは、ポモドーロ・テクニックを使って作業と家事を交互に行うと、作業も集中できるし、家事も片付くしで一挙両得だよ! というお話です。

ポモドーロ・テクニックって?

集中して仕事をこなすために、25分毎に時間を区切って仕事をする時間管理術。Francesco Cirillo氏が1992年、自身の勉強効率を上げるために考案した。

ポモドーロテクニックとは - はてなキーワード

詳しい方法は、上記のはてなキーワードの記事をご覧ください。

家事ポモドーロ・テクニックとは?

ポモドーロ・テクニックを応用して、一定時間集中して作業を行った後は、一定時間家事を行います。

自分の場合、飽きっぽいので15分で、集中して作業をした後、次の15分で家事を行っています。

そして、それを4セット(合計2時間)繰り返したら、長めの休憩を入れます。

家事ポモドーロ・テクニックの利点

実際にやってみたところ、作業を集中して行えるのはもちろんなのですが、他にも様々な利点がありました。

• 家事が精神的報酬に 家事は肉体労働なので、頭脳労働である作業の合間に行うことで、リフレッシュできます
• 家事の合間に、作業のアイデアが浮かぶ。作業だけを集中して行うより、より良い作業ができるようになりました。
• 家事も作業も片付く!

細かいテクニック

• やるべき家事をTODOリストに入れておくと、次何しようかと悩まなくて良くなります
• 家事も仕事も中途半端で終わせると、次やる時のコンテキスト・スイッチが少なくて良いです
  • きっちり終わらせると、次やることの精神的ハードルが高くなる

そんな感じで、家事ポモドーロ・テクニック。超おすすめです!!

アジャイルな時間管理術 ポモドーロテクニック入門

scope は、戻り値が `nil` や `false` のときも `ActiveRecord::Relation` を返す

条件式付きのscpoeをクラスメソッドに移行する際に、問題になる

例: scopeの場合

class Item < ApplicationRecord
  scope :by_name, -> name { where('name like ?', "%#{name}%") if name.present? }
end

引数の値が nil でも、 ActiveRecord::Relation がキチンと返ってくる

Item.by_name(nil).order(:created_at) #=> ActiveRecord::Relation

例: クラスメソッドの場合

class Item < ApplicationRecord
  def self.by_name(name)
    if name.present?
      where('name like ?', "%#{name}%")
    end
  end
end

この場合、Item.by_name に nil を渡すとエラーが発生する

Item.by_name(nil).order(:created_at) #=> NoMethodError: undefined method `order' for nil:NilClass

どうすればよいの?

nil の代わりに all を返せば ActiveRecord::Relation が返るようになる

  def self.by_name(name)
    if name.present?
      where('name like ?', "%#{name}%")
    else
      all
    end
  end

Item.by_name(nil).order(:created_at) #=> ActiveRecord::Relation