今さら聞けないDocker入門 〜 Dockerfileのベストプラクティス編今時のアプリ開発において、コンテナは避けて通れないものになっています。そして数多くあるコンテナ実行環境の中でも、デファクトスタンダードと言えるのがDockerです。そんなDockerのイメージですが、皆さんは正しくビルドできていますか? そのコンテナは無駄に太っていませんか? 効率よく最短時間でビルドできていますか? セキュリティは大丈夫ですか? 今回はDockerfileの書き方をテーマに、「今さら聞けない」Docker入門をお届けします。
Dockerfileのベストプラクティス８選
はじめに Dockerfileを書く上で、Docker社の推奨するベストプラクティスを８つにまとめました。 ベストプラクティスに従うことによって、簡単・安全・効率的な、Dockerfileの作成を目指します。 Dockerのガイドライン コンテナは、必要最小限（エフェメラル）であるべき。 Dockerfile で定義されたイメージを使って作成されるコンテナは、可能ならばエフェメラル（短命；ephemeral）にすべきです。私たちの「エフェメラル」とは、停止・破棄可能であり、明らかに最小のセットアップで構築して使えることを意味します。 Dockerfileベストプラクティス 1. Baseイメージは、公式の信頼できるものを使おう 特定の言語などを扱う場合は、公式が言語が入ったイメージを配布してくれている場合が多いので、そちらを使おう。
Elasticsearch + Sudachi + Docker でユーザー辞書を作ってみるハンズオン - Qiita
今回は Elasticsearch + Sudachi でユーザー辞書を使う Dockerfile を作ったので作り方を共有します。 Elasticsearchのバージョンは現行の最新(v7.4.0)ですがv6.8あたりでも動くことを確認済みです。 Sudachi とは Sudachi は日本語形態素解析器です。株式会社ワークスアプリケーションズ下の機関であるワークス徳島人工知能NLP研究所が開発しています。複数の分割単位をサポートしているなどの特徴があります。 ドキュメントはこちら https://github.com/WorksApplications/Sudachi/#sudachi-%E6%97%A5%E6%9C%AC%E8%AA%9Ereadme 今回のハンズオンの最終構成 最終的に下記のような構成を目指します。 . ├── docker-compose.yml └── elas
ElasticSearch + Kibana (7.2) を docker-copmose で秒殺起動する - らくがきちょう
ElascticSearch + Kibana の構成は鉄板ですが、毎回、ゼロからインストールのはやや手間です。 そこで、今回は docker-compose を使って秒殺で ElasticSearch + Kibana 環境を構築する手順をメモしておきます。 今回は CentOS 7.2 上に 7.2.0 の ElasticSearch / Kinaba を構築しました。 尚、docker や docker-compose がインストールされていない場合は CentOS7 に Docker ＆ Docker Compose をインストールする の手順を参考にインストールしておきます。 但し、docker-compose のバージョンは最新にしておくことをお勧めします。 ディレクトリ構成 最終的には以下のディレクトリ・ファイル構成を作ります。 # tree elasticsearch-ki
Dockerfile を書くためのベストプラクティス解説編
最近勉強を始めたコンテナ技術に関する基礎的な知識をまとめました。 [訂正と注釈] p.27-30: 「Deployment」内の「Version: 1」 => 「Version: 2」 p.37: 「終了コードをから」 => 「終了コードから」 p.39: 「HTTPSが利用できない」=> AWS上では、SSL終端するLBがサポートされています。https://kubernetes.io/docs/concepts/services-networking/service/#ssl-support-on-aws p.40: 「ユーザがingress controllerをmaster上にセットアップする必要」 => master上にセットアップしなければならないという制約はありません。例えばGCEのingress controller(GLBC)はPodとして動作します。https://gi
公式のRubyのDockerイメージのbundlerの挙動
少しハマったので備忘録。公式のRubyのDockerイメージを使うとbundler経由でインストールしたものをボリューム用コンテナで永続化しても二回目以降の起動時でうまく反映されない事象が起きました。 具体的には以下の手順でエラーが発生しました。 コンテナを立ち上げてコンテナ内に入り、bundle install –path=vendor/bundle で依存ライブラリをインストール。vendor/bundleはボリュームコンテナで永続化している。 bin/rails sでサーバ起動できることを確認 コンテナを再起動し再度コンテナ内に入り、bin/rails sでサーバ起動する。vendor/bundleはボリュームコンテナで永続化しているはずなのでbin/rails sを叩けば起動できるはず… が、エラーで落ちる Dockerfileとdocker-compose.ymlはこんな感じです
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DCSF19 Dockerfile Best Practices