こんにちは、Acroquest Technologyの横山です。 4/19(木)にKubernetesやDockerを中心としたコンテナ活用の現状をひとまとめにした開発者のためのイベントである「Japan Container Days v18.04」に参加してきました。コンテナの管理ツール（オーケストレーションツール）であるKubernetesを活用した事例が多数あり、とても刺激的でした。発表資料をまとめてくれている方がいますので、興味のある方は「Japan Container Days v18.04 の資料」を見てみてください。 はじめに 第三回では、各種Dockerコマンドの説明と、コンテナ内でTomcatインストールを行い、そのコンテナをDockerイメージにしました。 第四回では、Dockerfileを使ってDockerイメージを作成してみます。また、Dockerfileを使用する
ユニオンファイルシステムとコピーオンライト Docker コンテナが軽量だと言われる理由のひとつが、ユニオンファイルシステムにあります。ユニオンファイルシステムは、複数のファイルシステム上のディレクトリやファイルをレイヤとして重ね合わせ、それらを仮想的に一つのファイルシステムとして扱う技術です。 Docker は、このユニオンファイルシステムを使い、イメージを複数の読み取り専用レイヤのスタックとして扱います。コンテナ内ではさらに、読み書き可能なレイヤを一枚重ねています。 コンテナ上の読み書き可能なレイヤをコンテナレイヤと呼び、イメージを構成する読み込み専用レイヤをイメージレイヤと呼びます。 この構成により、同一ノード上で動く複数のコンテナが、Docker イメージを構成するイメージレイヤを共有することを可能にし、トータルとしてのコンテナサイズを最小化しているのです。 共有しているイメージレ
こんにちは。もーすけです。 コロナでの在宅に非常にしんどくなってきました。 ブログを書いて気を紛らわしていきたいと思います。 今回は軽めの話題でSkopeoを利用したコンテナイメージのレジストリ間のコピーについてです。 課題感 コンテナレジストリにあるイメージを別のレジストリにコピーしたいと思ったことはないでしょうか。 よくあるシチュエーションとしては、開発環境のKubernetesクラスタで生成したコンテナイメージをプロダクション環境などのほかのレジストリへ移したい。 あるいは、DockerHubにあるイメージを自分たちの管理するレジストリに保管して管理しておきたい。 などがあるかなと思っています。実際にあります。 さらに、このようなコンテナイメージの別レジストリへのコピーをCIパイプラインの中に組み込みたいといったことがあります。 Dockerではだめなのか まず真っ先にレジストリ間の
こんにちは、NTTの徳永です。本稿では、コンテナユーザなら誰もが使っていると言っても過言ではない、コンテナランタイムの筆頭「runc」に注目し、その概要を仕様と実装の両面から俯瞰します。本稿は私が主催者の一人として参加した「Container Runtime Meetup #1」で発表した内容をベースにしています。詳しい内容は発表資料もぜひご参照ください。 コンテナランタイムとはKubernetes等のコンテナオーケストレータを用いてアプリケーションをコンテナ(Pod)として実行するとき、実際にコンテナの作成をしているのは誰でしょうか。実はKubernetesはコンテナを直接触らず、あるソフトウェアを用います。まさにそれがコンテナランタイム（以降、ランタイム）です。つまり、ランタイムはクラスタを構成する各ノード上で稼動し、上位のオーケストレータからの指示に応じ実際にコンテナを作成・管理しま
![コンテナユーザなら誰もが使っているランタイム「runc」を俯瞰する[Container Runtime Meetup #1発表レポート]](https://cdn-ak-scissors.b.st-hatena.com/image/square/2757b228827ed0ff7a4891cb1dc730c4d4c6e047/height=288;version=1;width=512/https%3A%2F%2Ffanyv88.com%3A443%2Fhttps%2Fmiro.medium.com%2Fv2%2Fresize%3Afit%3A809%2F1%2AmFt37mfkCaV2P1rprRuwBw.png)
この記事は Kubernetes道場 Advent Calendar 2018 11日目の記事です。 今回はConfigMapとSecretについて。 ConfigMapとSecret ConfigMapやSecretはアプリケーションの設定やクレデンシャルをコンテナイメージから分離するために使われる。 ConfigMapやSecretをVolumeとして、または環境変数を通してPodに設定やクレデンシャルを渡す。 まずは作成の仕方から見ていこう。 ConfigMap / Secret の作成方法 主に2通りあり、 kubectl create コマンドを使った方法と、Manifestを使う方法がある。 kubectl createで作成する ConfigMapは kubectl create configmap またはリソース名の短縮形の kubectl create cm コマンドで作
Red Hat ソリューションアーキテクトの小島です。 エンタープライズ用途でコンテナアプリを開発・運用していく際には、コンテナイメージのバックアップ、バージョン管理、構成やセキュリティ基準の標準化などのいくつかの理由により、専用のコンテナイメージレジストリが必要になってきます。本記事ではKubernetesやOpenShiftなどのコンテナ環境に利用できる、分散型コンテナイメージレジストリQuayをご紹介します。 Quayとは Quayの提供形態 Operatorを利用したRed Hat Quayのインストールの前準備 Operatorを利用したRed Hat Quayのインストール (GUI) Operatorを利用したRed Hat Quayのインストール (CLI) Red Hat Quayの使用 Clairによるコンテナイメージ脆弱性の静的解析 まとめ References Qu
たとえば、インストール先として/dev/vdaを指定し、Ignitionの設定ファイルのURLが「http://192.0.2.100:8080/container/simple.json」、イメージファイルが「http://192.0.2.100:8080/container/fedora-coreos-31.20191127.1-metal.x86_64.raw.xz」の場合、次のようにcoreos-installerを実行すれば良い。 # /usr/libexec/coreos-installer -d vda -i http://192.0.2.100:8080/container/simple.json -b http://192.0.2.100:8080/container/fedora-coreos-31.20191127.1-metal.x86_64.raw.xz ちなみに
最近 Kubernetes 全然触ってねーなって思ってたところに、『6年ぶりぐらいにクラウド使った結果、Kubernetes以外のマネージドサービスとか基本要らなくない？となった話 – データエンジニアの酩酊日記』を見つけて、自分と異なる立場によるコンテナシステムへの感想を興味深く読ませていただきました。 Kubernetes を推す人がいる一方で、ここには昨夏『Kubernetes、はじめました』と言っておきながら今年に入って全然触らず、ECSを使ったシステムばっか手掛け、Kubernetes いらなくね？って思う人もいるわけで。これはいったいどういうことでしょう、と雑感タイムです。 どうしてコンテナシステムで迷うのか 最初に断っておきたいのは、以下 Kubernetes を否定したり腐すような意図は全くなく、なんでやろ？って自身に問いかけた私見です。やめました、と言ってもウチで今も使っ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
