サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
買ってよかったもの
www.unicorn.limited
実行中のコンテナ内にあるファイルをホストとの間でコピー転送するには、kubectl|docker container cpを使えます。 config類のベースファイルや実行ログを取得する場合などに便利です。 ## コンテナのファイルコピー kubernetes, dockerに`cp`サブコマンドがある * `kubectl cp [options] origin dest` * `docker container cp [options] origin dest` --- ## ファイルpath NFS同様 `[host:]/path/to/file` * ローカルは、`host:`のprefixなし * リモートpathにはタブ補完が効かない * kubernetesの`host`にはpod名を指定 * `kubectl get pods`で検索 --- ## kubectl用共通オプ
webpackをシンプルに導入すると、SPAのようにモノリシックなファイルにバンドルされますが、設定しだいでモジュール化も可能です。(モノリスなライブラリ作成ノウハウについては、 ES2015で静的なライブラリ塊をバンドルするで解説しています) 共有ライブラリのコンシューマー設定 たとえば、ReactJSを利用するプロジェクトでは、ライブラリのコンシューマー(アプリ本体)の冒頭で、以下のようにライブラリをインポートします。 import React from "react"; import ReactDOM from "react-dom"; class SomeComponent extends React.Component { (以下コード本体) webpackを特に意識せずにセットアップしてビルドすると生成されるJavascriptは、このアプリに加えてreact, react-d
kubernetesのインフラ運用の楽な点は、dockerコンテナとサーバーを切り分けて運用できる点です。 dockerのイメージが完成していれば、サーバーのクラスタを指定して起動するだけです。 ハードを交換する場合にも、OSレベルの環境バックアップ・構築はDockerで完結しているため、新しいクラスタを用意してコンテナを起動それば良いので、非常に手早く対応できます。 Google Kubernetes EngineのNode Pool Googleのkubernetesホスティングサービス”Kubernetes Engine”(GKE)は、Node Poolという機能を提供しています。 これはnode(仮想マシン)のグループを作成する機能で、1つのクラスタの中で複数の実行環境を管理するものです。 Google Cloudの多彩なサイズのマシンタイプ(n1-standard, n1-hig
kubernetsの実行環境はnode(ノード)と呼ばれます。実機サーバーの場合もありますし、Google Container EngineのようにVMインスタンスの場合もあります。 複数のノード・クラスタの上で、pod(コンテナ)が実行されます。 通常のコンテナ運用では、podがどのnodeに配備されるかはkubernetesが自動的に決定しているため、ノードを直接操作する必要はありません。 たとえば、Google Container Engineの場合は、2016年5月にリリースされた Node Pool機能を活用すればほぼ運用をカバーできると思います。 ただし、計画停止や明示的にノード操作を行いたいケースのために、kubernetes v1.2からノード操作用のコマンドが拡充されています。 cordon / uncordon でコンテナ配備を制約 kubectl cordon som
ローカルPC上のdockerは唐突に終了する場合が多くあります。このような利用を続けていたら、コンテナの利用していたポートをつかんだままになり、コンテナ再起動時にエラーに遭遇しました。 ERROR: for mysql Cannot start service mysql: driver failed programming external connectivity on endpoint data_mysql_1 (fdc978c2f074ff810c5ddaf6e1bd36b6bf47f54be440a2ab8abea1b009bec421): Bind for 0.0.0.0:3306 failed: port is already allocated ERROR: Encountered errors while bringing up the project. ホスト上のlso
Google Compute Engineのmicroインスタンス(f1-micro)上のサービスが安定せず、何度再起動しても数日でハングアップする、という挙動に遭遇しました。 dockerがコンテナごと終了するケースが多発し、またVMごとハングアップすることもありました。 結論から言うと、swap領域を設定していなかったため、600MBの物理メモリを使い切った瞬間にプロセスが停止していました。 環境を切り分けて安定稼働して欲しい目的でコンテナを使うのですが、コンテナは1プロセスに過ぎないので、ホストOSの必要性しだいで簡単にkillされるようです。 oom-killerの状況確認 サービス停止の原因が、メモリ不足によるプロセス停止によるものである場合、/var/log/messagesにoom-killerのログが残されます。grepで、該当の事象が起きていることを確認できます。 $ s
dockerは多彩な開発環境がそれぞれパッケージ化されていて便利なのですが、継続的に使っていくうちに過去のコンテナ関連ファイルがあふれてディスク容量を圧迫していきます。 とくに、MacOSなどの環境では、Macの中にLinuxの環境が作られる構成となり、Linux用のファイルシステムを使い切るとコンテナが起動しなくなります。 “No space left on device”のバリエーション コンテナが起動しないケースで、docker logs _some_container_name_を実行して、”No space left on device”のようなエラーが出力されている場合は、ディスク領域が枯渇しています。また、docker-composeでまとめて起動した際に同時多発で異常終了する症状も特徴的です。 そのほか、イメージビルド中に”No space left on device”エ
docker hubはデファクトのdockerイメージレジストリで、各種公式イメージの流通・取得のために現状使わざるを得ない部分があります。 ただ、ID・パスワードやSSL鍵などのクレデンシャルを含むイメージを公開するわけにはいかないのと、あやまって素性の知れないイメージをつかんでしまうセキュリティリスクがあるため、自作のイメージ管理にはプライベートなレジストリ(イメージ置き場)を利用した方が安全です。 実行環境としてGoogle Compute Engineを利用する場合、Googleのホスティングサービスを利用する方法と、google製のdockerイメージを自分で構築する方法の2つが手軽です。 Google Container Registry Google Container RegistryはGoogleがホストするdockerレジストリです。 事前にセットアップすることなくすぐ
React.jsは、ネイティブアプリのようにインタラクティブなUIを作りやすくするためのJavascriptライブラリです。 従来、Webサービス分野ではjQueryが近い機能を果たしてきましたが、React.jsはJSXの導入によりDOM操作に引きずられることなく、より凝集性の高いコードを書けるよう設計されています。 Railsプロジェクトとの組み合わせ方 RailsプロジェクトとReact.jsベースのクライアントコードは大ざっぱに分けて、以下のような3つのパターンが考えられ、それぞれメリット・デメリットがあります。 react-railsを利用してAsset Pipelineに組み込む Railsのビルド手順に組み込まれるため、新たに準備すべきものは少ない。一方、Javascript側のツールチェインをうまく使えず柔軟性が低い SPAのようにJavascript主体でアプリを作り切り
Google Container Engine(GKE)など、クラウドインフラ上でdockerコンテナを動作させる場合、データ確保のため外部ディスクを利用するケースが多々あります。 GKEでは、設定ファイルにpersistentDiskの設定を記述することで、dockerコンテナにpersistentDiskがmountされた状態で起動します。 この場合、外部ストレージのファイルパーミッションが問題となり、コンテナが起動できないトラブルによく遭遇します。 (AWSではためしていませんが、kubernetesではEBSも指定できるので、問題の構造は同様でしょう) 典型的な用途では、mysqlはmysqlユーザー、postgresqlはpostgresユーザーでDBディレクトリを読み書きできる必要があります。 そのため初回起動時にpersistentDiskのファイルオーナーを各ユーザーに変更
多くのdockerイメージは単体デーモンが起動する形式で作られているため、コンテナ内のコマンドを実行する手順が思いつかなくなりがちです。 このような場合、たいていはdocker execコマンドの理解を深めることで必要な操作をカバーできます。 ## docker exec `ssh`不要でコンテナ操作可能 * コンテナ内でコマンドを実行できる * `-it`オプションで端末にコンテナに接続できる --- ## オプション * `-i` 標準入力を接続。ローカルの`cat`出力リダイレクトにも使える * `-t` 仮想端末の接続 * `-u user` ユーザー指定 --- ## コンテナ内で作業 `docker exec -it CONTAINER bash` * `bash`ではなく`rails c`などでも良い * bashは`exit`または`Ctrl-d`で切断 --- ## do
dockerは「1コンテナ=1サービス」で動作させる前提で設計されているため、一般的なWebサービスを構築したいケースでは複数のコンテナをネットワーク接続することが事実上必須になります。 たとえばRuby on Railsのアプリの場合、標準的な機能範囲でもrubyコンテナに加えて、MySQL/PostgreSQL、nginx/Apacheの計3つのコンテナが必要になります。 これらのサービスを1コンテナに詰め込もうとするとトリッキーなイメージを構築する必要があり、のちに何かを追加したくなった際に行き詰まる可能性があります。 基本的には開発用PCの環境を構築する段階からdockerのネットワーク構成に対応しておくことが重要です。 dockerネットワーク設定の流れ dockerのネットワーク設定のおおまかなステップは、以下の3段階に分かれます。 ネットワークを作成する 任意の名前をつけるこ
APIリクエストデータの調べ方 kubernetesを操作する具体的なAPIを調べるには、kubectlで操作してみて対応するリクエストデータを見る方法が便利です。kubernetsを操作するkubectlコマンドはREST APIのラッパーになっています。 kubectlの各コマンドを実行する際にkubectl --v=8 get podsのように–v=8オプションをつけることで、REST APIレベルでリクエスト/レスポンス情報を確認できます。 KubernetesのコンテナからAPI serverを利用する Kubernetesの各podからAPIサーバーを利用できます。APIサーバーはBasic認証で保護されているため、リクエスト時にクレデンシャル情報を付加する必要があります。 Basic認証のuser名とpassword文字列は、Google Container Engine(G
Ruby on Railsの標準的なデータベース定義ツールはActiveRecordの”マイグレーション”です。これは、データベース定義の変更点をSQLではなくRubyスクリプトで記述し、バージョン管理を可能にするものです。 ただ、マイグレーションはDB定義の変更が増えてくると無数のファイルが生成されて見通しが悪くなります。 ridgepoleを使うことで、マイグレーションと同様の記法でDB定義を1つの設定ファイルに集約でき、冪等な設定で運用できるようになります。また、RDBMSのドライバーを切り替えることで、PostgreSQL / MySQL / SQLite などデータベース間のスキーマ移行も簡単になります。 旧聞ながら、 クックパッドにおける最近のActiveRecord運用事情の説明から、クックパッド本サービスの大規模環境で利用されていることが分かります。 同じ目的のツールに s
この文書は、kubernetesユーザーズガイドの「The life of a pod」の和訳(参照した原文は release-1.0版)で、一部意訳や不正確な部分が含まれているかもしれません。kubernetesは Apache License v2.0で提供されています。 2015/4/14更新 このドキュメントはpodのライフサイクルについて解説している。これは網羅的なドキュメントではなく、このトピックへの紹介文である。 podのフェーズ API規約全体と一貫するため、フェーズはpodのライフサイクルの推移のハイレベルのシンプルなサマリーになっている。これはコンテナレベルやpodレベルの状態の観察結果を体系的にとりまとめたり、その他の状態を表すことを意図したものではないし、包括的なステートマシンを意図してもいない。 PodPhase の値の数と意味は厳格に保護されている。ここで説明さ
kubernetes(読み方はクバネティス)は、多数のコンテナをクラスターとして一元管理するツールです(kとsの間に8文字あるため、”k8s”と略記されることもあります)。 原語”κυβερνήτης”[ギリシャ語]は「操舵手」の意味で、dockerやコンテナなど船に関連したモチーフをとっています(なお、サイバネティクスも同語源のようです)。 単機能のコンテナをつなげてシステムを組み上げる「オーケストレーション・ツール」と呼ばれる分野の管理ツールで、Googleが主体的に開発に参画しているオープンソース・ソフトウェアです。 dockerは実行環境をポータブルにコンテナ化する機能を持ち、kubernetesはコンテナの稼働継続やコンテナ間ネットワーク、ストレージなどの機能を提供しています。 kubernetesとdocker-composeが競合していましたが、kubernetesがNo.1
このページを最初にブックマークしてみませんか?
『www.unicorn.limited』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く