kasei_sanのブログ

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

ruby:2.3.6-alpine3.4 に、postgresql-dev 9.6系をインストールしようとしたら conflict が発生した話

docker alpine ruby postgresql

現象

alpine3.4 だと、postgresql-dev や client が 9.5 系

9.6 系を入れたくて、Dockerfileで /etc/apk/repositories を加工して、alpine3.5系のパッケージを入れるように変更した

/etc/apk/repositories

  http://dl-cdn.alpinelinux.org/alpine/v3.5/main
  http://dl-cdn.alpinelinux.org/alpine/v3.5/community

するとこんなエラーが

ERROR: unsatisfiable constraints:
  openssl-dev-1.0.2n-r0:
    conflicts: 
               libressl-dev-2.5.5-r0[pc:libcrypto=1.0.2n]
               libressl-dev-2.5.5-r0[pc:libssl=1.0.2n]
               libressl-dev-2.5.5-r0[pc:openssl=1.0.2n]
    satisfies: .ruby-rundeps-0[openssl-dev]
  libressl-dev-2.5.5-r0:
    conflicts: 
               openssl-dev-1.0.2n-r0[pc:libcrypto=2.5.5]
               openssl-dev-1.0.2n-r0[pc:libssl=2.5.5]
               openssl-dev-1.0.2n-r0[pc:openssl=2.5.5]
    satisfies: 
               postgresql-dev-9.6.8-r0[libressl-dev]
  build-dependencies-0:
    masked in: cache
    satisfies: world[build-dependencies]

ruby は OpenSSL を postgresql-dev は LibreSSL を使っているため、 複数のSSLLibraryが混在してconflictが発生している様子

原因

alpine linux が 3.5 になった時に、OpenSSL から LibreSSL に切り替わったのが原因 そのため、alpine3.4系に、3.5系のSSLを使うライブラリを入れるとConflictが発生する

alpinelinux.org

日本語の記事

gihyo.jp

対策

諦めた

springの子プロセスが `BUNDLE_APP_CONFIG` を無視するバグがある

Rails docker bundler

現象

docker-compose を使って、run bin/rake を実行した時に、Could not find rake が発生

(ローカル環境では正しく動作する)

$ docker-compose exec web bundle exec bin/rake --version
Could not find rake-12.3.0 in any of the sources
Run `bundle install` to install missing gems.

発生したバージョン

ruby 2.5.0p0 (2017-12-25 revision 61468) [x86_64-linux-musl]
rake, version 12.3.0
Rails 5.1.4
gem 2.7.6
Bundler version 1.16.1

何故発生するのか?

ruby の docker image では 環境変数 BUNDLE_APP_CONFIG を設定している

  • 環境変数 BUNDLE_APP_CONFIG は、bundler の設定ファイルの場所を特定する環境変数
  • 未設定の場合は、./.bundle

以下のissueによると、springの子プロセスが bundler/setup を参照するときに、bundler が正しいconfigの場所を参照しなくなるとのこと

github.com

対策

  1. issue にあるように BUNDLE_APP_CONFIG を使わない
  2. springを使わない

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

docker

ビルド

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 を作った

docker Rails

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 のテキストリンク修飾は使えないので諦める

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

f:id:kasei_san:20180308220403p:plain

詳細

感想

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

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

docker

今日やること

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にした方が良い

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 読書メモ

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

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

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

はじめに

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

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

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

www.slideshare.net

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

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

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

解説スライド

資格について

f:id:kasei_san:20180228220100p:plain

  • 資格の期限は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