コンテナ未経験新人が学ぶコンテナ技術入門
最近勉強を始めたコンテナ技術に関する基礎的な知識をまとめました。 [訂正と注釈] p.27-30: 「Deployment」内の「Version: 1」 => 「Version: 2」 p.37: 「終了コードをから」 => 「終了コードから」 p.39: 「HTTPSが利用できない」=> AWS上では、SSL終端するLBがサポートされています。https://kubernetes.io/docs/concepts/services-networking/service/#ssl-support-on-aws p.40: 「ユーザがingress controllerをmaster上にセットアップする必要」 => master上にセットアップしなければならないという制約はありません。例えばGCEのingress controller(GLBC)はPodとして動作します。https://gi
gao-ji-ji-kontenahosuteinguniokerubotorunetukutosofalsejie-fa?slide=137
話し手の所属するGMOペパボではロリポップ！マネージドクラウドというコンテナホスティングサービスを提供しており、1台のサーバに数千のコンテナを起動します。 コンテナはプロセスであるという認識は一般的になりつつありますが、コンテナプロセスを起動するにはネームスペースの作成や、マウントなどいくつもの処理が行われてプロセスを起動する必要があり、通常のプロセス起動と違う箇所にボトルネックが現れます。またコンテナ技術はLinuxのカーネルレイヤに近い領域で実装されているためそのボトルネックの解消には深いLinuxに対する理解が必要です。 本セッションにおいては話し手が1台のサーバで数千のコンテナを起動する際に直面したボトルネック、その調査方法、そして解決する方法を共有したいと思います。 昨今k8sの台頭により、あらゆるサービスでコンテナ技術が利用されつつありますが、コンテナ技術の深い理解は、今後のエ
Key Characteristics of a Container Orchestration Platform to Enable a Modern Application
Need Help? US & Canada: +1 800 678 4333 Worldwide: +1 732 981 0060 Contact & Support About IEEE Xplore Contact Us Help Accessibility Terms of Use Nondiscrimination Policy Sitemap Privacy & Opting Out of Cookies A not-for-profit organization, IEEE is the world's largest technical professional organization dedicated to advancing technology for the benefit of humanity. © Copyright 2023 IEEE - All rig
Kubernetes対応コンテナランタイム「containerd 1.1」正式リリース。CRIにネイティブ対応し、Dockerより軽量で高速な動作を実現
Kubernetes対応コンテナランタイム「containerd 1.1」正式リリース。CRIにネイティブ対応し、Dockerより軽量で高速な動作を実現 コンテナ型仮想化を実現するDockerは、その内部にコンテナランタイムとしてcontainerdと呼ばれるソフトウェアを内蔵しています。 このcontainerdはもともとDocker社によって開発されてきましたが、標準的なランタイム実装を実現するために、Docker社から中立的な団体であるCloud Native Computing Foundationに（CNCF）に、2017年3月に寄贈されました。 コンテナ実装の一本化へ向かうか。DockerとCoreOSがそれぞれのコンテナ実装をCloud Native Computing Foundationへ寄贈すると協同提案 － Publickey containerdは現在もDocker
コンテナの軽量さと、より安全な分離を実現する「gVisor」、Googleがオープンソースで公開
Googleがオープンソースで公開したgVisorは、準仮想化のような仕組みを用いて従来のコンテナよりも安全性を高めたコンテナランタイムだ。Kubernetes時代の標準コンテナランタイムとなる有力候補かもしれない。 Dockerなどに代表されるコンテナ型仮想化は、OSのユーザー空間の名前空間を分離することなどで実現されています。 この仕組みの利点は、あらかじめ起動されているOSの上で名前空間を分離するだけでコンテナが起動できる点にあります。これがコンテナの迅速さや軽量さにつながっている一方、コンテナ間でOSのカーネルを共有しているためにコンテナ間の分離レベルは高くなく、同一OS上で稼働している別のコンテナの負荷の影響を受けやすかったり、コンテナからOSのシステムコールを直接呼び出せることなどによるセキュリティ上の課題を引き起こしやすくもあります。 OCIに準拠し、runc互換のgViso
Open-sourcing gVisor, a sandboxed container runtime | Google Cloud Blog
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
How Linux Containers Work - Sasha-Goldshtein_How-containers-work.pdf
Shared with Dropbox
Dockerコンテナが遅くなるもう一つの原因 | POSTD
前回の ブログ記事 では、Kubernetesの話と、 ThoughtSpot がKubernetesを開発インフラのニーズに合わせてどのように取り入れたかをご紹介しました。今回はその続報として、最近の興味深いデバッグ経験について少々駆け足になりますがお話ししていきます。本記事も「コンテナ化と仮想化はノットイコールである」という事実に基づいており、たとえcgroupの上限がどれも高くない値に設定されホストマシンで十分な演算能力が利用できるとしても、コンテナ化されたプロセス同士がリソースの競合を起こす場合があることを示したいと思います。 ThoughtSpotでは内部のKubernetesクラスタで 多数のCI/CDや開発関連のワークフロー を稼働させており、ある1点を除いては全てが順調でした。唯一問題だったのは、ドッカー化された製品コピーを起動すると、パフォーマンスが期待を極端に下回るレベ
Exploring container security: An overview | Google Cloud Blog
Containers are increasingly being used to deploy applications, and with good reason, given their portability, simple scalability and lower management burden. However, the security of containerized applications is still not well understood. How does container security differ from that of traditional VMs? How can we use the features of container management platforms to improve security? This is the
initのお仕事〜tiniのコードを読んでみた - ローファイ日記
急にinitが何をしているのか、何をすべきなのかが気になったので調べてみた。一緒に600行強のinit実装であるtiniのソースコードをざっくり読んだ。この場を借りてメモしていく。 the PID 1 problem RubyコミュニティなどではPassengerで有名なPhusion社のブログに、Docker and the PID 1 zombie reaping problemという記事が掲載されている。 blog.phusion.nl ゾンビプロセスをreapしてくれないと困る SIGTERMなどでPID=1が先に死んだらその子プロセスを処理してくれないと困る みたいな内容が書いてある。詳細は読んでみてほしい。 システムコンテナ（参考）と呼ばれる種類のコンテナを作る場合、任意のプログラムをコンテナ内部のPID=1とするのではなく、上記のような振る舞いをする軽量なinitプログラムを
SCONE: Secure Linux Containers with Intel SGX | USENIX
Sergei Arnautov, Bohdan Trach, Franz Gregor, Thomas Knauth, and Andre Martin, Technische Universität Dresden; Christian Priebe, Joshua Lind, Divya Muthukumaran, Dan O'Keeffe, and Mark L Stillwell, Imperial College London; David Goltzsche, Technische Universität Braunschweig; Dave Eyers, University of Otago; Rüdiger Kapitza, Technische Universität Braunschweig; Peter Pietzuch, Imperial College Lond
cri-o
Designed Optimized for Kubernetes Stable Committed to passing Kubernetes tests Any Image, Any Registry Pull from any compliant registry; run any OCI-compliant container Try Now Minikube: Use CRI-O as the container runtime kubeadm: Checkout this kubeadm guide to setup kubeadm to use CRI-O Kubic: Configured to use CRI-O out of the box in both its kubeadm and microOS system roles Join #crio on Kubern
Dockerコンテナ時代の第一章の終わり、そして第二章の展望など － Publickey
コンテナ型仮想化の技術や実装はDockerが登場する以前から存在していたとはいえ、IT業界で本格的にコンテナの活用が始まったと言えるのは、やはり2013年3月に当時のdotCloudからDockerが登場したことがきっかけでしょう。 そうして始まったコンテナ時代の第一章は今年2017年、コンテナの標準仕様がOpen Container Initiativeによって策定完了し、コンテナオーケストレーションの事実上の標準がKubernetesに決まったことで基盤技術の基本要素がおおむね固まり、一つの区切りがついたように見えます。 そして今後は、この基盤技術を用いたコンテナによる分散アプリケーションのための様々なサービスや開発、テスト、デプロイ、本番環境に対応したツールやサービス実行環境などのソリューションが登場し、競う段階へ入っていくのではないでしょうか。 この記事では、Docker登場から現
大コンテナ時代を生きのこるためのJSON Schema - Sexually Knowing
実行環境をコンテナ化するDockerが普及して久しく、CIやローカルの開発環境などどこかでコンテナ技術に触れているのではないでしょうか。 コンテナはその性質上、設定のプロビジョニングに古典的な設定ファイル (のパス) 受け渡しが難しいです。etcdやconsulのようなKVS (= Key-value store) を用いることもあるでしょうが、素朴には環境変数で与えることが多いでしょう。 HerokuはThe Twelve-Factor Appというパターンを提唱し、その中でStore config in the environmentと述べています。 The twelve-factor app stores config in environment variables (often shortened to env vars or env). Env vars are easy to
latest
Cloud services editions Fully managed in the public cloud of your choice Red Hat OpenShift Service on AWS Jointly managed and supported by Red Hat and AWS Microsoft Azure Red Hat OpenShift Jointly managed and supported by Red Hat and Microsoft Red Hat OpenShift Dedicated Managed offering available on AWS or Google Cloud Red Hat OpenShift on IBM Cloud Jointly supported by Red Hat and IBM; managed b
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
コンテナは次世代サービスの主流になるか？
Container Isolation at Scale (... and introducing gVisor)
Container Networking Deep Dive
JapanContainerDays v18.12
ContainerとName Space Isolation
