はてなブックマーク

Docker ID で swarm クラスタへサービスをデプロイできるというもの。 そもそも評価環境や本番環境へは、ビルドはもちろんテストグリーンが保証された CI/CD 環境などからデプロイされるべきだろうし、開発中にローカルでない環境で ちょっと確認してみたいというレベルなら docker-machine でもいいだろうし 何がいいものかいまいちわからなかったのでさわってみました。 まとめ Desktop to Cloud Docker for Mac などで行われる認証を利用して ユーザごとに利用可能な swarm クラスタの一覧表示 （関連付いた組織にもすぐスイッチできる） （管理下にある Docker イメージの一覧も並ぶ） あとはクラスタを選択するだけで クラウド上の swarm クラスタに繋がったターミナルが起動 Docker Cloud が使うプロキシ型ではなく個別 TCP

DockerCon 2017 で発表された Moby プロジェクト を利用して LinuxKit が動作するところまでを確認します。 Moby もともと使われている意味の Moby Docker 社のロゴにもなっている、このクジラの愛称1。 (https://blog.docker.com/2015/06/winners-dockercon-2015-contests/ より拝借) 最近チラ見せしていた Moby OS Alpine Linux ベースの軽量 OS。Docker for Mac の記事でよく Message of The Day のアスキーアートとともに紹介されていますが Docker for AWS などでは Docker Inc. が用意したであろう Moby な AMI で EC2 クラスタが起動するなど、 Docker 製品群では近頃大活躍している OS です。 M

Amazon ECR はとても便利ですが、ECS 以外でのデプロイとなると 適切なインスタンスプロフィールが与えられた EC2 であっても 例えば CLI の aws ecr get-login で得られる値をもって docker login しないと接続ができませんでした。 最近素晴らしいツールが公開されたので、改めて Qiita に記事を残します。 Amazon ECR credential helper 公式のツールとして GitHub にソースコードとインストール方法、使い方が公開されています。 https://github.com/awslabs/amazon-ecr-credential-helper Docker v1.11 で実装された credential-helper のインターフェースを実装した プラグインという形になっており、利用方法もこれに準じています。 インスト

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? AWS re:Invent 2016 で発表された AWS Batch。 語感から、誤解されるサービス No.1 な気がします。 定時バッチなどとは何がどう違うのかをメモ。 機能概要 以下公式資料とドキュメント、実際さわってみた所感を合わせて。 AWS Batch – 簡単に使えて効率的なバッチコンピューティング機能 – AWS AWS Black Belt Online Seminar「AWS Batch」の資料およびQA公開 結局何なのか 科学技術計算・ハイパフォーマンスコンピューティング用途で真価を発揮する、 大規模なスケール、ジ

DeepLearning Advent Calendar 2016 4 日目です。 3 日目は @tereka114 さんの「グレーの画像に色をつけるネットワークについて発表しました。」でした。 最近 AWS が公式にサポートを表明した深層学習フレームワーク MXNet に、彼らの記事や各種チュートリアルを通して入門してみようと思います。 MXNet とは 概要 MXNet はワシントン大学とカーネギーメロン大学によって、CNN と LSTM をサポートするために開発されはじめました。効率的で柔軟な深層学習フレームワークとなるよう設計されています。 特徴 AWS が MXNet を支援すると決めた理由に、以下の 3 つをあげています。 スケーラビリティ 豊富な対応言語 軽量かつ高い可搬性 その他にも MXNet には以下のような特徴があります。 命令的 / 宣言的プログラムの混合 豊富な深

パターン AWS のマネージドを中心に CI / CD パイプラインを組むなら ECS ElasticBeanstalk CodeDeploy Docker for AWS を用途に応じて使い分けられます。 用途 自分でクラスタを管理したい / しなければならないといった特別な理由がなければ、ECS がオススメです。最近 Datadog も ECS の本番利用が増加していることを記事1にしています。 メリット コンピュートリソースを最大限有効に利用できる ALB との併用で動的ポートマッピングが有効に Service Auto Scaling でスケールも AWS に任せられる タスク単位で IAM ロールを使った適切な権限管理ができる Spot fleet 上での運用でコスト最適化も CloudWatch でクラスタとしてのメトリクスも扱える 構成例 継続的デプロイ例 ElasticBe

更新履歴 [2017/03/08] AWS 公式 Deep Learning AMI v2 リリース！ CUDA 8.0 になり、TensorFlow v1.0.0, MXNet v0.9.3 など Deep Learning に便利な AMI NVIDIA 提供 NVIDIA CUDA Toolkit 7.5 on Amazon Linux NVIDIA DIGITS 4 on Ubuntu 14.04 2016/09 末に公開された模様。 自分で CUDA をインストールしたことがある方ならわかると思いますが、NVIDIA の GPU ドライバから始まり、CUDA をインストールするのはなかなかの手間でした。（まあ、一度 AMI を作ればってのはありますが） この AMI を使えば、ものすごく簡単にサーバが使い始められます！ AWS 提供 Deep Learning AMI Amazo

前回に引き続き、今回は Docker for AWS で生成される swarm クラスタで実際に アプリを起動させたりスケールさせたりしてみます。 （ 8月1日出版予定の AWS 本で ECS や ECR の章書きました！ AWS での Docker 利用の手引きにぜひご参照ください） 目次 通常の Swarm クラスタとの違いは、docker service をご覧ください。 Swarm マネージャに接続する docker node docker service 続編.. Swarm マネージャに接続する 2 つ方法 があります（いずれも Docker を利用する上で一般的1 なもので Docker for AWS や Swarm クラスタならではというわけではありません）。 Docker ホストに SSH ログインして、ホストの Docker クライアントから直接操作 SSH トンネル

DockerCon 2016 で発表され、現在 プライベート β 公開中の Docker for AWS。 Docker 社にブログ書くよアピールをしたら招待されたのでこれ書いてます。 目次 Docker for AWS 概要 CloudFormation で起動するリソース・構成 EC2 インスタンスとそのプロファイル（IAM ロール） 続編について Docker for AWS とは Docker 社の提供する AWS のマネージドサービスとうまく統合された、いい感じの Swarm クラスタを **「CloudFormation テンプレート + 専用 AMI」**で構成するツール群。 AWS への Docker クラスタデプロイツール。 ただの Swarm クラスタではなく、AWS ならこう構成するといいよね！なクラスタが起動します。 制約・前提 2016/07/15 現在プライベー

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

CLI を使ってみる run : 新しいアプリケーションの起動 Nginx を起動してみます。 arukas run --instances 1 --mem 512 -p 80:tcp nginx （instances と mem は必須の引数で、それぞれ起動数と使用メモリ量です、たぶん） 返ってきた結果に ENDPOINT という列がありますが、これに https:// をつければ、Nginx のハローページが表示されます。なんて簡単に立ち上がるんだ・・便利な世の中だ・・ run : 引数多め版 Arukas.io で Slack 自動招待フォーム のアプリを起動してみます。 arukas run --app-name slack-test --name=slack --instances=1 --mem=512 -p 80:tcp -e SLACK_TEAM_NAME=MYTEAM -

オフィシャルでない Alpine イメージを使うなら 上の表の通り、最近はオフィシャルでも Alpine 版があったりしますが なければ、サイズの小さなサードパーティ製でも全然よいと思います。 選ぶなら、最低限 Automated Build で作成されており Dockerfile から操作履歴が明瞭なもの4 がよさそうです。 ADD / COPY をしているものは GitHub に行けば中身を確かめることもできます。 もしくは、まるっとコピーして自分でイメージを作るのも手です。 アプリのベースイメージに Alpine いずれにせよ、特定 OS のシェルを直接叩くようなアプリでない限り、 Alpine はとてもいい選択肢と言えそうです。 Golang 製でもなければ5、Alpine でよさそう。 参考資料でサイバーエージェント山田さんが 書かれている ように 重いイメージはほんとにいいこと

結論 以下の手順で作るのが効率的です。 ベースにする Docker イメージを決める docker run -it <docker-image> sh でコンテナ内部で作業 1行ずつ、うまくいったらどこかにメモ 失敗したらいったん exit して再度 docker run ファイルの取り込みやポートの外部公開が必要ならオプション付きで docker run 全部うまくいったら Dockerfile にする ネットで見たことはないですが、もし docker build で試行錯誤しながら Dockerfile を作るとしたら、それはさすがに苦行です。 遅い デバッグしにくい！コンテナ爆発しろ！！って気持ちになります。 これが原因で「Docker 使えない 便利じゃない 」と思っていたのならそれは勘違いです。 手順詳説 試しに ip-api.com にリバースプロキシするだけの Nginx イ

ChatOps ファンのみなさんこんにちは。今日も Slack してますか？ 先日これを読んで、Slack、この先生きのこると確信しました。 Slackがカップル専用アプリだった件 - くまのからあげ さてそんな Slack、 チームを公開して 参加希望者に自由に参加してもらう には 公開Slack用 自動招待フォーム by GAS1 などの方法で あれこれ準備せねばなりません。 他に Heroku の例 などもありますが、無料2で簡単に 実現すべく 今回は β公開中の Arukas.io でやってみたいと思います。 手順 1. Arukas.io でアカウント作成 https://arukas.io/ 支払方法の登録もなく。シンプルすぎる。 2. 新しいアプリケーションの作成 https://app.arukas.io/ の以下の画面で 「新しいアプリケーションを作成」 3. アプリケー

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Go その2 Advent Calendar 2015 2日目です。 今日書くこと APIを提供するためのコード APIを利用するためのコード マイクロサービス (･∀･)ｨｨｲｲ!! かもしれない やれなかった / この記事には書いていないこと 以下サンプルで利用するコードは こちら。 お手元で起動する1 ための手順は READMEをご覧ください。 APIを提供するためのコード Go言語には APIのためのよさげなフレームワークはありますが、 今回はそれらを使わずともかんたんに APIサーバが作れることをお伝えしたく。 ベースとなっている元ネタは A RESTful Micro-Framework in Go これなのですが ここから、やりたいことができるように変えていった結果をサンプルに、 どうすれば APIサーバが書けるのかを記します。 まず、APIのエンドポイントが実装すべきインタ

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

前提 インフラ？やっといたほうがいいの？な方への記事です。 正確な説明や比喩よりも、わかりやすさを優先します。 過去記事であがった未解決な課題 前回 04.Dockerのよさ（前編）で解決しなかった残課題。 第2回の構成管理では OSによっては構成管理が期待通りに動かない 同じ定義書を利用しても、隣の人とまったく同じ環境になる保証がない そもそもプロジェクトごとに定義書作るのは（煩雑さが緩和されず）やっぱり大変 第3回のクラウドでは スナップショットからは作業履歴を追いにくい サーバスペックは複数種類からの選択で、それでは過剰もしくは不足 ポータビリティが下がるベンダーロックインの心配 サーバ単位でDisposable Componentsするのは時間的金銭的に非効率 Dockerとはなにか 前回に引き続き、4以降の詳細をみていきましょう！ 4.1 gitのように commit, push

まだDockerの話にはなりません・・ 前提 インフラ？そんなの仕事じゃないよ？な方へ向けた記事です。 正確な説明や絶妙な比喩よりも、わかりやすさを優先します。 構成管理って Dockerが注目されている理由やメリットを理解するためには ここでいったん、仮想化とはちょっと違った視点で 構成管理にも触れなければなりません。 構成管理とは、簡潔すぎて微妙な言い方をすれば ソフトウェアのインストールと設定を管理すること です。 インストール・設定問題、山積 「ホームページ作って ！」と言われたら ApacheかNginxあたりをググりましょう。 でも「Ruby使いたい 」とか「Pythonで書いてね 」と続いたら そのプログラミング言語やWebフレームワーク1の用意が必要です。 これ、いざやろうとすると悩ましいことばかり。 たとえば PHPはどのバージョンを使おう そのPHPと相性のいいApac

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 今回はVagrantのメリットまでですが・・ この連載のゴール 連載の最後まで読んでいただくと Dockerとは何か、どんなメリットがあるのか より理想的な開発環境とはどんなものか、テスト環境や本番環境への影響は？ といったことがわかるようになります。おそらく。 前提 サーバーを自分でセットアップしたことのない方、ようこそ！ そして黒い画面1に不慣れな方、ようこそ！ 以下、インフラ？そんなの仕事じゃないよ？な方に向けた記事です。 正確な説明や絶妙な比喩よりも、わかりやすさを優先します。 ケース: 開発環境セットアップ 突然ですが、 「会

前提 以下、インフラ？誰かに頼むから大丈夫！な方への記事です。 正確な説明や比喩よりも、わかりやすさを優先します。 これまであがった課題など 明確に書いていなかったものも含め、こんな課題がありそうです。 初回の仮想化では * 環境間の差異を完全になくすことはできない1 ひとつの仮想環境で利用できるOSはひとつに限定されてしまう2 仮想環境の中で何が動いているのか、外からはわかりにくい 前々回の構成管理では OSによっては構成管理が期待通りに動かない 同じ定義書を利用しても、やはり隣の人とまったく同じ環境になる保証がない ひとつのプロジェクトで、複数バージョンのソフトウェアを同時に使うのは依然困難 そもそもプロジェクトごとに定義書作るのは（煩雑さが緩和されず）やっぱり大変 前回のクラウドでは サーバは数分で起動するが、数分は決して速くない スナップショットからは作業履歴を追いにくい サーバス