Open-sourcing gVisor, a sandboxed container runtime Containers have revolutionized how we develop, package, and deploy applications. However, the system surface exposed to containers is broad enough that many security experts don't recommend them for running untrusted or potentially malicious applications. A growing desire to run more heterogenous and less trusted workloads has created a new inter
Dockerイメージを公開するのにGitLabが最⭐高だったので紹介します。GitHubとDockerHubを使うより遥かに良いです。 以前GitLabを使っていくと言ったんですがその続報です。 nownab.log | GitLabを使うぞ この記事のGitLabという言葉はだいたいSaaS版のGitLab.comを指しています。 なにがいいの 特にいいと感じているのはこの2つです。 とにかく簡単 ✨ とにかく速い 🚀 もう2つ大きいのは次の2つです。 GitLabだけで完結する 無料で無制限 ってところです。 どれぐらい簡単なの 簡単なサンプルを用意しました。 nownabe / docker-sample-app · GitLab GitLabでDockerイメージを公開する場合、このようにDockerfileと.gitlab-ci.ymlを用意するだけです。他にはProject1
Google、Dockerイメージに対するテスト自動化フレームワーク「Container Structure Tests」オープンソースで公開 Container Structure Testは、コンテナ内部でコマンドを実行することで正しい出力やエラーが帰ってくるかどうかや、コンテナ内部のファイルが正しく格納されているかなどの検証を実行できるフレームワークです。 具体的には下記のテストをサポートしていると説明されています。 Command Tests コンテナイメージ内部でコマンドを実行し、正しい出力やエラーが返ってくるかを検証する。 File Existence Tests コンテナイメージ内部に、あるファイルがファイルシステム内の適切な位置に存在しているかどうかを検証する。 File Content Tests コンテナイメージ内のファイルシステムにあるファイルのコンテンツとメタデータ
The easy way to save screenshots, GIFs, and websites. Make everyone happy by sharing smarter, faster, and with your… 単純にスクリーンショットを保存するだけなら OS の機能だけでも十分ですが、GIF 動画を保存できたり、いつどこでどんなアプリケーションを利用しているときに撮影したのか、あるいは画面にどんな文字が写っているかといった情報を元に検索できたり、保存した画像をコレクションという単位でまとめて共有できたりと、Gyazo を使って保存しておくと意外と便利なことが多く、個人的にも重宝しているサービスの1つです。 我々が開発環境で Docker を使うメリットGyazo のサーバサイドの実装には、プログラミング言語の観点で見ると Ruby、Go、JavaScript などが
Kubernetes and Docker Swarm are both popular and well-known container orchestration platforms. You don't need a container orchestrator to run a container, but they are important for keeping your containers healthy and add enough value to mean you need to know about them. This blog post introduces the need for an orchestrator then chalks-up the differences at an operational level between these two
[追記] この記事の内容について訂正 この記事内、及び Speaker Deck に投稿したスライドの中で誤っていた箇所があったため、訂正致します。 「ECS Optimized AMI では ecs-agent のバージョンが固定されない」という内容ですが、そういった問題はありませんでした。 AWS の方から直接アドバイスを頂いたところ、弊社が使用していた User Data のスクリプト内で $ yum update を実行していたことが原因となっていました。 $ yum update によりインスタンスを新規に立てた際に常に最新の ecs-agent や Docker がインストールされていました。 そのため、ECS Optimized AMI によってインストールされる ecs-agent と Docker のバージョンは以下のドキュメントで提示されているバージョンが常にインストー
Introducing GitLab Container Registry Built on open source software, GitLab Container Registry isn't just a standalone registry; it's completely integrated with GitLab. Yesterday we released GitLab 8.8, super powering GitLab's built-in continuous integration. With it, you can build a pipeline in GitLab, visualizing your builds, tests, deploys and any other stage of the life cycle of your software.
RailsのECS移行事例なんて既に山ほどあるので、特に書くつもりは無かったのですが、実際にやってみると 時代が進んで、より便利なものが出てきている デプロイどうするのよ、となったときに各自が最強のECSデプロイツールを作っていて、参考にならない といった体験をしたので、最近やったECS移行の話を書くことにしました。 社内Qiitaに書いたポエムです pic.twitter.com/yDlWGhhkF1— wata (@wata727_) 2017年8月31日 もちろん、この記事も古くなると何の役にも立たないと思うので、古くなったら、みなさん頑張って調べてください。 ECS移行で考えるべきこと まず前提として、移行対象はシンプルなRailsアプリで、WebサーバとWorkerからなります。デプロイはCapistranoなどのいわゆる「Push型」で行っていたものとします。Railsに限定し
ペパボ研究所主席研究員の松本です。Twitter上ではまつもとりー(@matsumotory)と呼ばれています。2017年の6月24日に開催された、第38回インターネットと運用技術研究会で、「FastContainer: Webアプリケーションコンテナの状態をリアクティブに決定するコンテナ管理アーキテクチャ」について研究発表してきました。 論文(研究会予稿)とスライドを以下に公開します（論文画像をクリックするとPDFで読むことが出来ます）。 論文(研究会予稿) スライド FastContainerを一言で表現すると、コンテナの状態遷移（停止・起動・複製・資源割り当ての変更処理など）の速度を効率化することに着目し、システム全体として恒常性を持ち、コンテナが高速に循環可能なWebサービス基盤を実現することによって、突発的なアクセス集中やライブラリのバージョンアップのような運用について効率的に対
追記 直近の Docker 界隈について Linux コンテナ 参考 Linux コンテナとは Linux コンテナを構成する主な機能 OS リソース毎の Namespace cgroup サブシステム こんなにざっくりでは、Linux コンテナは語れないと思うけど haconiwa haconiwa とは haconiwa で何が出来ると？ haconiwa 導入 はじめての haconiwa (1) はじめての haconiwa (2) 〜 コンテナ作成 〜 はじめての haconiwa (3) 〜 コンテナ起動 〜 haconiwa で学ぶ Linux コンテナ .haco ファイル再掲 namespace を弄る前に namespace uts namespace pid 俺は Linux コンテナについてなんにも解っていなかった(まとめ) haconiwa は Linux コンテ
Enterprise Kubernetes Management From datacenter to cloud to edge, Rancher lets you deliver Kubernetes-as-a-Service.
「Kubernetesはオープンソースのコンテナオーケストレーションのデファクトになった」と、CoreOSがfleetの開発を終了、代わりにKubernetes採用を発表 Dockerの競合としてコンテナに最適化したContainer Linux（旧CoreOS）などを展開するCoreOSは、これまで同社が推進してきたコンテナオーケストレーションツール「fleet」の開発を終了し、今後はKubernetesを採用すると発表しました。 today we are seeing widespread adoption of Kubernetes, which has become the de facto standard for open source container orchestration. 現在、Kubernetesは広く使われており、オープンソースのコンテナオーケストレーションと
Dockerのネットワーク構成について整理する。 図1: Dockerネットワーク全体図 物理NICが1個ついたDockerホストに2つのコンテナを立てると、図1のようになる。コンテナは172.17.X.Xのネットワーク内にいて、ホスト側には172.17.0.1のIPアドレスが付く。この構成自体は、VirtualBoxで言うところのホストオンリーネットワークと同じようなもの。異なる点として、Dockerネットワークは、ハードウェア仮想化ではなく、Linuxカーネルの機能であるvethペアとブリッジを組み合わせて実現される。 図2: vethペア veth (virtual Ethernet) は、図2のように、仮想NICのペアと、それをつなぐ仮想ケーブルを作る機能。ふたつの仮想NICはイーサネットで直接通信できる。 図3: ブリッジ ブリッジとは、LinuxマシンがL2スイッチ（スイッチン
https://amakan.net/ のこの辺の改善の続き。 amakanをUnicornからPumaに移行した - ✘╹◡╹✘ amakanでyarnを使うようにした - ✘╹◡╹✘ amakanでRuby 2.3.3を使うようにした - ✘╹◡╹✘ amakanを Ruby 2.3.3 から 2.4.0-preview3 に移行した - ✘╹◡╹✘ amakanのフロントエンドを色々改善した - ✘╹◡╹✘ amakanをSidekiqに移行した - ✘╹◡╹✘ amakanの開発環境をDockerに移行した - ✘╹◡╹✘ 本番環境で使うDockerイメージ これまで開発環境でのみDockerを動かしていたが、本番環境でDockerを動かすには、本番環境で利用できるようなDockerイメージを用意する必要がある。そこでamakanでは、こういう方法を取った。 開発環境と本番環境で同
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
