『ネットワーク初心者の新卒がDockerでネットワークの勉強をしてみた』
こんにちは！サイバーエジェント アドテクスタジオ新卒の黒崎 (@kuro_m88) と申します。 Dynalystというチームに配属され、一人前のサーバサイドエンジニアになるべく修行をしています(｀・ω・´)最近はScalaを書くことが多くて、Sparkで大量のログを集計するバッチの開発をしています。ほぼ100%AWSで構成されているプロダクトなので業務でネットワークの運用もしませんし、構成の事を意識する事はあまりありません。 そんな中でネットワークの事が知りたくなったのは、広告の配信に関わる開発をしてみて、広告の配信の仕組み自体も技術的にめちゃくちゃ面白いんですが、それと同時に自分たちのサーバから広告が表示される端末までの間がどうなってるのか気になってしまったのがきっかけです。学んでいくにはやはり手を動かすのが一番ですよねo(((^^)))o
EC2 Container Service(ECS)を管理して、Blue-Green Deploymentを実現するツールを書いた - tehepero note(・ω<)
2015-07-22 EC2 Container Service(ECS)を管理して、Blue-Green Deploymentを実現するツールを書いた AWS Docker ECS 最近は暑いのでめっきり外に出なくなりましたが、相変わらずDevOpsのOpsばっかりやっています。 さて、今やってるプロジェクトではAmazon EC2 Container Service(ECS)で完全にDockerベースでの開発をしています。本番運用を見越したオペレーションの作り込みをやってるわけですが、今回はBlue-Green Deploymentを実現してみたよってお話。 材料 必要な材料は以下の通り。 VPC Route53 EC2 ELB AutoScaling Group ECS 方式 最近ELBがAutoScaling Group単位での切り替えができるようになったので、これを利用します。基
HashiCorpの新プロダクトNomadとOttoを触ってみた | DevelopersIO
ども、大瀧です。 VagrantやTerraformで有名なHashiCorpのカンファレンスイベント、HashiConf 2015が今朝未明からポートランドで開催されています。そこでNomadとOttoという2つの新サービスが発表されました。両方とも発表直後に公開され、試せるようになっているのでサンプルを動かしてみた様子をレポートします。 Nomad by HashiCorp Otto by HashiCorp Nomad NomadはEasily deploy applications at any scaleというリード文からあるように、アプリケーションをデプロイするスケジューラです。あらかじめアプリケーションを実行するホストにエージェントをインストール、アプリケーションをジョブとして設定ファイル(*.nomad)に定義しておき、設定ファイルに従ってジョブを実行します。 デプロイツー
なぜベンチャーで docker を使うのか - Qiita
昨年ごろから急に docker って流行り出しましたよね。 https://www.docker.com/ 僕も docker のチュートリアルをひと通りやってなんとなくコマンド覚えたんですけど、chef で良くない？ってなって結局使わずじまいでした。 ただ、最近になって、ちょっと思い直している部分があって、 Docker は Kubernetes 使ってこそだろーと思って勝手に自社サーバ持ってる企業だけが恩恵にあずかれると思っていたのだけど、その管理はクラウド屋さんに任せて dockerfile 書いておけば dev/stg/prd 全て共通だよっていう享受の仕方もありかな、と。 — C. Hasegawa (@_c_hase) 2015, 8月 27 ということです。 おそらく同じような懸念をいただいている方はそれなりの数いると思うので、なんとなく疑問に思っていたことを綴ってみようかと
プログラマのためのDocker超入門 04.Dockerのよさ（前編） - Qiita
前提 以下、インフラ？誰かに頼むから大丈夫！な方への記事です。 正確な説明や比喩よりも、わかりやすさを優先します。 これまであがった課題など 明確に書いていなかったものも含め、こんな課題がありそうです。 初回の仮想化では * 環境間の差異を完全になくすことはできない1 * ひとつの仮想環境で利用できるOSはひとつに限定されてしまう2 * 仮想環境の中で何が動いているのか、外からはわかりにくい 前々回の構成管理では OSによっては構成管理が期待通りに動かない 同じ定義書を利用しても、やはり隣の人とまったく同じ環境になる保証がない ひとつのプロジェクトで、複数バージョンのソフトウェアを同時に使うのは依然困難 そもそもプロジェクトごとに定義書作るのは（煩雑さが緩和されず）やっぱり大変 前回のクラウドでは サーバは数分で起動するが、数分は決して速くない スナップショットからは作業履歴を追いにくい
コンテナー: Docker、Windows、および動向
最近では、コンテナーについて話すことなしに、クラウド コンピューティングの議論をすることはできません。銀行や金融サービス会社からECサイトまで、すべてのビジネスにわたる組織は、コンテナーとは何か、クラウドにおけるアプリケーションにとってコンテナーは何を意味するか、コンテナー固有の開発/IT運用シナリオでどのようにコンテナーを最大限に利用するかについて、理解したいと考えています。 皆さんがよりシームレスにクラウド アプリケーションを構築、テスト、デプロイ、管理するために、この重要なクラウド コンピューティング開発を最大限に活用する方法を理解するのを助けるため、コンテナーとは何か、コンテナーがどのように動作するかという基本から、現在、コンテナーが最も幅広く使われているシナリオ、「コンテナー化」をサポートする現れつつある動向まで、私の観点を共有しようと思います。 コンテナーの概要 抽象的な言葉で
HeapsterでKubernetesを使わないDockerコンテナのリソース監視 - Qiita
はじめに 前回、cAdvisorのInfluxDB連携機能を試しましたが、やはりHeapsterも試してみます。 前回はcAdvisorが直接InfluxDBにデータを入れたが、Heapsterを使う場合、HeapsterがcAdvisorのAPIを呼び、HeapsterがInfluxDBにデータを入れるという形になる。 そのため、Heapsterは監視対象のサーバーを知っている必要がある。ドキュメントには書かれていないが、ソースを見るとこの方法は３つ用意されている。 Kubernetesから取得 CoreOSのFleetから取得 設定ファイルから取得 今回はKubernetesもCoreOSも使わない環境を想定しているので、3番目の設定ファイルから取得を試してみる。Kubernetesを使わないのにHeapsterを使う需要はないかもしれませんが… ※なお、これも3月中旬に試した時の内容
cAdvisor, InfluxDB, GrafanaでDockerコンテナのリソース監視 - Qiita
はじめに 1台のDockerホスト上のコンテナのリソース監視はcAdvisorが一般的になっているような気がします。 それでは複数台のDockerホスト上のコンテナのリソース監視はどうするのかなと調べてみると、以下のような方法があるようです。 cAdvisorで直接InfluxDBに保存し、Grafanaで可視化 HeapsterでcAdvisorから情報を収集してInfluxDBに保存し、Grafanaで可視化 cAdvisorからfluentでInfluxDBに保存し、Grafanaで可視化 この記事では一つ目の方法を試してみようと思います。 とりあえず今出てきた登場人物の簡単な紹介とリンク紹介を。 なお、この記事はだいたい3月中旬に書いた内容です。 Dockerコンテナのリソースモニタリングツール Kuberenetesで使うために主にGoogle社が開発したオープンソースソフトウェ
CoreOSとKubernetesを統合した「Tectonic」、CoreOSが発表
Linuxコンテナに最適化した「CoreOS」を提供するCoreOS社が、同社のCoreOSおよび関連ソフトウェア群と、Linuxコンテナのクラスタを管理する「Kubernertes」を統合したパッケージ「Toctonic」を発表しました。 TectonicのWebサイトでは、Tectonicとは次のようなソフトウェアだと説明されています。 Tectonic combines Kubernetes and the CoreOS software portfolio in an integrated package. This includes a management console for workflows and dashboards, an integrated registry to build and share Linux containers, and additional
RHEL7におけるDockerのディスクイメージ管理方式 - めもめも
変更履歴 2014/04/20 公開 2014/04/27 構成情報ファイルの説明追加 2014/06/15 dm-thinprovisiongのデバイスメタデータファイル変更 背景 先だって、「Linuxコンテナ(LXC)の基礎をまとめ直す」というコラムに、「来るべきDockerの波に向けて、まずは、コンテナの基礎を理解しましょう！」的な話を書きました。この中で、比較的に原始的なコンテナ利用法として、「RHEL6.2のlibvirtからLinuxコンテナを利用」という記事を紹介しています。 この記事では、busyboxを使った簡易httpサーバのコンテナを起動していますが、この手順に従うと（気づく人は）容易に気づくのが、コンテナに見せるファイルシステムの準備がいかに面倒か、という事実です。コンテナから見えるルートファイルシステムは、基本的には、ホスト上の特定のディレクトリにchrootし
Fedora Atomic Host on EC2 with KubernetesでDockerコンテナのクラスタリング - Qiita
はじめに Redhatが本気でやってそうなので企業内で使うならばProject Atomicが最有力なのではないかなと、Fedora Atomic Hostを使ってEC2上でDockerコンテナのクラスタリングを試してみました。 タイトルはKubernetesと書いていますが、Atomicに入っているCockpitとかも一通り試します。 Project Atomicが何者かは、このスライド「Docker on RHEL & Project Atomic 入門 - #Dockerjp 4」が大変わかりやすいです。 試した時点の各ソフトウェアのバージョン だいぶ前ですが、試したのは2015年2月17日なので以下の情報はその日付時点の情報です。 Fedora-Cloud-Atomic-20141203-21.x86_64でrpm-ostree upgradeで入った最新バージョンです。 Kube
Dockerの諸問題とRocket登場の経緯
2014年の後半あたりからDocker，Docker Inc.への批判を多く見かけるようになった（もちろんもともと懸念や嫌悪を表明するひとはいた）．それを象徴する出来事としてCoreOSチームによる新しいコンテナのRuntimeであるRocketのリリースと，オープンなアプリケーションコンテナの仕様の策定を目指したApp Containerプロジェクトの開始があった． CoreOS is building a container runtime, Rocket 批判は，セキュリティであったり，ドキュメントされていない謎の仕様やバグだったり，コミュニティの運営だったり，と多方面にわたる．これらは具体的にどういうことなのか？なぜRocketが必要なのか？は具体的に整理されていないと思う．これらは，今後コンテナ技術を使っていく上で，オーケストレーションとかと同じくらい重要な部分だと思うので，ここ
Docker、IBM、Microsoft、RedHatがGoogleのコンテナ管理フレームワークKubernetesにこぞって開発参加する理由 - Qiita
Docker、IBM、Microsoft、RedHatがGoogleのコンテナ管理フレームワークKubernetesにこぞって開発参加する理由GoogleAppEngineDockergooglecomputeenginekubernetesGoogleCloud Kubernetes is 何 先週末、Docker、IBM、Microsoft、RedHatがGoogleのコンテナ管理フレームワークKubernetesに開発参加を表明して話題になったが、この連携がどんな意味を持つのかすぐにピンときた方はどの程度いるだろうか。その前に、Kubernetesって何？ Dockerとどう関係するの？ 読み方すら分からないんだけど……って反応が多いと思う。 Googleのソフトウェアエンジニアで、Kubernetesの開発者であるBrendan BurnsによるGoogle I/O 2014のセッ
OSTree: OSイメージとパッケージシステムの間にGitのアプローチを
This document discusses OSTree, a system for deploying and managing operating system updates using Git-like technologies. It describes how OSTree works with Linux distributions and containers to provide atomic operating system updates using technologies like Git, Docker, and chroot. OSTree aims to provide fast, reliable operating system updates similar to technologies used in Chrome OS and CoreOS.
Docker Private Registry + Mirror + Web UI - Qiita
私はいつも Vagrant を使って boot2docker や CoreOS をローカルマシンに VM として立てて、いろいろテストしています。 で、テストの度に VM を再構築して、テストで使う Docker のイメージを Docker Hub からダウンロードすることになるんですが、遅い回線だと大変イライラします。 まあ、ローカルマシンは回線もメモリも制約があるから、クラウド使えよって話なんですが。。。 他の案としては、ローカルに Docker Registry を立てて、そこに置けばいいんじゃないのってことですよねー が、最近 Docker Registry Mirror の存在を知って、これは！ ってなったので、使ってみることにしました。 Docker Hub のイメージをそのまま使いつつ、一度ダウンロードしたイメージはミラーにキャッシュされるので、次回からは超速で docker
Docker Private Registry の WebUI を発見したので試してみました。 - Qiita
docker_registry構築@boot2docker - Qiita Dockerのプライベートリポジトリをちょっとだけ使いやすくしてみる - Qiita を読ませて頂いた後、docker-registry-frontend っていうのを Docker 公式ドキュメント Docker Registry API Client Libraries の中で発見しましたので、試してみました。なかなか良さそうです。 VAGRANTFILE_API_VERSION = "2" DOCKER_REGISTRY_HOST = "docker-registry" Vagrant.configure(VAGRANTFILE_API_VERSION) do |config| config.vm.define "docker-registry" config.vm.box = "yungsang/boot2
Atomic HostのCockpitを使ってDockerコンテナを操作 - tsunokawaのはてなダイアリー
概要 前回Atomic Host(CentOS)を起動させました。 Atomic HostのCentOSイメージをVirtualBoxで動かしてみる - tsunokawaのはてなダイアリー 今回はAtomic Hostに内包されているCockpitをつかってDockerコンテナの操作を行ってみます。 Cockpitログイン画面 ポート番号 9090 ユーザ名 centos パスワード 前回エントリー参照 Cockpitはデフォルトで起動するようになっていました。 なのでブラウザでポート9090に接続すると上記ログイン画面が表示されると思います。 Cockpitホスト一覧 Cockpitに登録されているホスト一覧です。 今はAtomic Host(CentOS)を動かしているローカルのマシンのみなので1台だけ表示されています。 ホストアイコンをクリックすると上記のようなホスト情報の画面が表
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
注目すべきDockerの周辺技術 PanamaxとKubernetes
Dockerイメージ構築 実践テクニック
404 Page not found
