docker-machine で localhost でポートを公開する - QiitaDeleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
kubernetes : kubectlコマンド一覧 - Qiita
よく使うkubernetesのkubectlコマンド一覧 1) podを作成 kubectl create --save-config -f [Pod定義ファイル] または kubectl apply -f [Pod定義ファイル] とりあえずapplyにしておくのがベター。 applyの場合は、前回実行時とのyaml設定の差分を抽出して、 その差分を反映するらしく、createたけで作成すると差分抽出の ための履歴情報がないため、createだけの後のapplyではエラーとなる。 ただし、create --save-configとしておけばcreateでもOK。 2) rs(Replica Set)を作成 kubectl create --save-config -f [rs定義ファイル] or kubectl apply -f [rs定義ファイル] rsを作成すると、複数のpodを一括管
Kubernetes: v1.6 の Role-Based Access Control (RBAC) を minikube で試す - Qiita
Kubernetes 1.6 で Role-Based Access Control (RBAC) が beta になり、デフォルトのロールの拡充や kubectl からロールの紐付けができるようになったりと大幅にアップデートされました 。以下は v1.6 の RBAC と minikube で試す際のメモになります。 v 1.6 での RBAC の主な変更点 デフォルトロールの拡充。汎用的に使える読み取り専用ロール (view) や 書き込み権限ロール (edit) などが用意されました。 kubectl のサブコマンド create rolebinding/clusterrolebinding が追加され簡単にロールの紐付けができるようになりました API Server の --anonymous-authがデフォルトで有効になりました 認証を通さない場合、RBAC ではsystem:
Docker で client is newer than server と怒られたら docker-machine upgrade する - Qiita
[hoge@localhost ~]$ docker-machine upgrade default Waiting for SSH to be available... Detecting the provisioner... Upgrading docker... Stopping machine to do the upgrade... Upgrading machine "default"... Default Boot2Docker ISO is out-of-date, downloading the latest release... Latest release for github.com/boot2docker/boot2docker is v1.11.0 Downloading /Users/hoge/.docker/machine/cache/boot2docker
Minikubeを触ってみる、gcr.ioのプライベートレジストリからimageをpullしてみる - Qiita
Kubernetesのクラスタをローカルで作れるminikubeへの手を付け方をまとめる。 kubernetes/minikube: Run Kubernetes locally https://github.com/kubernetes/minikube 現在最新バージョンは0.18.0。 What is Minikube? Minikube is a tool that makes it easy to run Kubernetes locally. Minikube runs a single-node Kubernetes cluster inside a VM on your laptop for users looking to try out Kubernetes or develop with it day-to-day. シングルノードのkubernetesを作って実験と
docker-compose "up" " run" "start" コマンド 違い - Qiita
docker-compose up 👉 docker-compose.ymlで定義したサービスを開始または再起動する デフォルトは「アタッチド」モードであり、全てのコンテナのログが画面上に表示される。 「デタッチド」モード（ -d ）では、Compose はコンテナを実行すると終了するが、コンテナは後ろで動き続ける 。 docker-compose run 👉 「ワンオフ」（one-off；１つだけ、偶発的） または「アドホック」（adhoc；臨時）なタスクを実行 する 実行するにはサービス名の指定が必要であり、特定のサービス用のコンテナを起動し、かつ依存関係のあるコンテナも起動する 。 テストの実行であったり、データ・ボリューム・コンテナに対するデータの追加・削除といった管理タスク。 run コマンドは実際には docker run -ti。 コンテナに対してインタラクティブなターミ
kubernetes: pod(コンテナ)のディスク(volume)とパス(path)の指定方法 - Qiita
コンテナを起動する際、dockerの場合はdocker runコマンドのオプションで色々指定できるが、kubernetesの場合は、pod（またはreplication controller）作成時に指定するyaml/jsonで規定する。 kubernetesでコンテナ（pod）を作成する際の、データの格納場所（volume）を指定する方法を記載する。 コンテナ(Pod)が死んでしまうと、データが消滅してしまうので、Volumeに格納しておく事で、状態を維持できる。 タイプは様々提供されている。 •emptyDir •hostPath •gcePersistentDisk •awsElasticBlockStore ほか emptyDirは、Pod単位の仮想ボリュームで、Podがdeleteされると同時にデータも削除される。 hostPathは、ホストサーバ上のDiskにマウントする方式。
Kubernetes 速習会 - Qiita
この速習会の目標 Developer がさくっと kubernetes を理解して、実際にリリース出来る kubectl が叩ける用になる Kubernetes の manifest ファイルの書き方 Kubernetes への Release / Deploy 方法 Kubernetes 上にあるApplication の maintenance Kubernetes に上げたApplicationのMonitoring kubectl を install kubectl の install してなかった場合は、こちらの実行ファイルを直接ダウンロードして叩けるようにしましょう The linux kubectl binary can be fetched with a command like: curl -O https://storage.googleapis.com/kuberne
Kubernetes クラスタの外からのアクセスに ClusterIP をロードバランサとして使う - Qiita
はじめに Kubernetes を触り始めて困惑したのは、クラスタの外からどうやってアクセスするのか？ということでした。 GKE なら提供されているロードバランサを使えば良いですが、GKE に頼れない環境でも良い方法が欲しいものです。 ClusterIP はクラスタ内部からアクセスする際に使用するもので、外部からアクセスすることは意図されていませんが、 これをそのまま利用できればとても楽ができそうです。 ClusterIP へのアクセスは複数の Pod に対して振り分けられるので、Ingress や Service Load Balancer が無くてもクラスタの外に対してロードバランサを提供することができます。 調べたところ Project Calico と kube-proxy を利用するとクラスタの外から ClusterIP にアクセスできたので、やり方をまとめておきます。 テスト環
KubernetesにデプロイするDockerコンテナのログ形式を選ぶ - Qiita
TL;DR; プログラム的にparseやすい、構造化されたログメッセージを採用するとよいです。 また、構造化されたログメッセージにするためには、 ndjson形式(俗称? jsonlog) bunyan形式 logfmt形式 のいずれかをおすすめします。 なぜ構造化されたログメッセージがよいか? アプリケーションによって、デバッグや稼働確認、障害調査等の目的でログに含めたいデータは異なります。 アプリケーションの部分部分を担当したエンジニアによって、ログに含まれるデータのフォーマットが異なると、それが利用しづらい状態になってしまいます。 また、 KubernetesのCluster-Level Loggingにはfluentdが使われるということと、 アプリケーションが後の分析のためにログメッセージに付与しておきたいメタデータと、アプリケーションが動作している環境との関連付けのためにKub
Kubernetes: Image Policy Webhookとは - Qiita
Kubernetesの1.4で追加されそうなImage Policy Webhookというイメージの制御ができる機能が面白そうだったので概要をまとめてみました。 Image Policy (Image Provenance)とは Image PolicyとはKubernetesクラスタ上で動かすコンテナイメージを独自に制御したい場合に使える仕組みです。Proposalのドキュメントによると下記のようなユースケースを想定しているようです。 既知の脆弱性を含まないことを確認されたイメージだけを動かしたい 特定のベースイメージを使ったイメージだけを動かしたい レビュー済みのコードでビルドされたイメージだけを動かしたい 署名されたイメージだけを動かしたい Image Policy Webhookは、ユーザが定義するWebAPIに対してそのPodに含まれるコンテナイメージの情報を渡し、実行可否をチェ
Kubernetes の各リソースに対するメモ - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? (追記): この記事は Kubernetes 1.3 世代という大昔に自分自身の学習過程のメモとして書いたので、現在は全く推奨しません。1.9 準拠の入門 Kubernetes などを足がかりにした上で最新のドキュメントを参照するのがオススメです。 Kubernetes の Glossary について大体目を通したので、これからリソースごとに概要をまとめていく。 この記事は自分自身が API の更新を把握して説明するための資料として API 一覧を軸にまとめる。 別の軸でまとめた Glossary の要約には下記などがあり。 http:
OpenStack on Kubernetes 最新動向まとめ - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに OpenStack を使えば AWS のようなインフラがオンプレミスでも簡単に利用できます。しかしながら、OpenStackクラスタ 自体について継続的にCI/CDを回すのはとても難しく、ある程度以上の規模になると運用上のボトルネックになることが課題となっております。 この課題を解決するためには、デリバリプロセス自体を Microservice に対応したもの(Kubernetes)に置き換えれば良いのではないか..ということで、2016年初頭あたりから、OpenStack on Kubernetes の PoC (Proof
Kubernetes 1.4の変更点 - Qiita
Kubernetes 1.4が出たので変更点をざっとみてみました。主に下記の情報を参考にしています。 Kubernetes 1.4: Making it easy to run on Kubernetes anywhere Kubernetes Feature tracking board (1.4 release) ScheduledJobs (alpha) ScheduledJobsというcronに相当するスケジュールベースのジョブの仕組みが追加されました。 下記のようなyamlでジョブを設定するようです。(マニュアルより) apiVersion: batch/v2alpha1 kind: ScheduledJob metadata: name: hello spec: schedule: 0/1 * * * ? jobTemplate: spec: template: spec: c
Kubernetes: クラスタ構築が簡単になるkubeadm - Qiita
Kubernetes 1.4の新機能としてkubeadmというkubernetesクラスタ構築を大幅に簡略化するための仕組みが入りました。1.4の時点ではalpha機能のため本番環境の構築には今後のバージョンを待つ必要があります。 マニュアルに沿ってGoogle Compute EngineのVMで実際に試してみました。 概要 下記の4手順で簡単にKubernetesクラスタを作ることができるようになりました。(Dockerのswarm join/initのイメージ) 関連パッケージのインストール kubeadm initでマスターを初期化 kubeadm join --token xxxx yyy.yyy.yyy.yyyでワーカーを追加 Podネットワークのデプロイ これでクラスタの構築が完了します。 準備 GCPで下記のVMを3台(Master1, Worker2)作成しました。 マシ
Spark + Kubernetes Docker on SoftLayer by Rancher - Qiita
Spark Summit 2016 San Franciscoが終わったというところで、RancherというDockerコンテナ管理ツールを使って、SoftLayer上にkubernetesを利用したSparkのクラスタ環境を簡単に構築してみた記録です。 まずは、それぞれの概要を記します。 Rancher Rancherは、Dockerイメージとして配布されているコンテナやクラスタの管理をWebUIで簡単に行えるオープンソースのツールです。 SoftLayer、GCP、AWS、Azure、DigtalOcean、rackspaceといった、各種クラウドとのコンテナ連携が可能です。 2016年3月にバージョン1.0になり、Kubernetes、DockerSwarm、Mesos等のクラスタ環境管理機能が追加されました。 公式サイト：http://rancher.com/ Spark Spar
逆引き Kubernetes オブジェクト - Qiita
kind: DaemonSet apiVersion: extensions/v1beta1 metadata: name: logstash spec: template: metadata: labels: app: daemon spec: volumes: - name: log hostPath: path: /var/log/myapp containers: - name: logstash # ホストの /var/log/myapp/myapp.log を出力するだけのコンテナ image: logstash args: - -e - | input { file { path => '/log/myapp.log' } } output { stdout { codec => rubydebug } } volumeMounts: - name: log # ホストの /
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MobyプロジェクトとDockerの位置づけ - Qiita
Docker MachineでDドライブなどUsers以外を自動マウントする - Qiita
https://qiita.com/ongstar/items/ec3b71c581b2b362aa3d