The Quay application could not be loaded, which typically indicates an external library could not be loaded (usually due to an ad blocker). Please check the JavaScript console for errors.
The Quay application could not be loaded, which typically indicates an external library could not be loaded (usually due to an ad blocker). Please check the JavaScript console for errors.
Docker Advent Calendar 2014 12/25 の記事、本気で使う Docker です。 ということで、実際に弊社で Docker を使った運用を開始した際にはまったところや、悩んだ所、どういう風に使っているのかについてぱらぱらっと書こうと思います。 "本気" なぜ Docker を使うのか、というと、僕の中では以下のような理由があります。 すべてのアプリケーションを(インフラ的に)同じ方法でデプロイ、管理したい 特定のサーバー / インスタンスの状況に依存することなく、アプリケーションの依存とインフラ都合の依存を別管理したい Docker なんかかっこいいっぽいし使ってみたい 上記のような都合から、どうやって作っていくかを考えていきます。基本的には1番目と2番目の理由が重要です。 Docker コンテナのいいところ とある Rails アプリケーションをデプロイするた
はじめに Amazon Linux AMI 2014.03でDockerが公式yumリポジトリに登録された事により、コンテナベースでのデプロイが現実的な選択肢となってきました。 一般的なアプリケーション開発のデプロイ環境としては、開発を行うStaging環境とサービス稼働環境としてのProduction環境に分離することが多いですが、コンテナベースでも同様にStagingとProducitonを分離することになるでしょう。そうした場合、作成したコンテナイメージをローカルに管理する仕組みが必要になります。 そこで今回はこのローカルでDockerのコンテナイメージを管理する仕組み、docker-registryをAWS上に構築してみました。docker-registryによるデプロイイメージは以下の形です。Staging環境で作成したコンテナイメージをdocker-registryにPushし
はじめに コンテナイメージは index.docker.io にだけ保存出来ると思っていたら個人でもリポジトリを持てるらしい しかも、コンテナイメージを Amazon S3 に保存出来るらしいので課金に注意しつつ*1そちらで試してみる! 尚、リポジトリの環境自体もコンテナイメージで配布されているのでそちらを利用する docker-registry は Gunicorn という python の WSGI HTTP サーバーで実装されている 参考 docker-registry S3-backed Private Docker Registry Deploying your own Private Docker Registry 準備 docker-registry コンテナイメージを pull してくる せっかくなんで docker クライアント for MacOS X でやってみる。 d
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く