Efficient Container Image Updating in Low-bandwidth Networks with Delta Encoding
はじめに まず確認すべきはNIST SP 800-190 Yahoo! JAPAN 製品選定に際し目指していた業務フロー 振舞い検知 構成チェック 脆弱性検知 製品選定 体制と役割 システム構成 ZOZOテクノロジー コンテナイメージ脆弱性検知 freee 外部から受ける攻撃の対策 イメージの脆弱性排除 podの挙動監視 node内の検知 Cluster内のネットワーク監視 感想 はじめに CNDT2020において、コンテナセキュリティに関連するセッションが複数ありました。 event.cloudnativedays.jp 自分自身が今後、マイクロサービス化を推進する立場になった時の為に、コンテナセキュリティにどう取り組むべきかを、各社の事例を参考にまとめておこうと思います。 まず確認すべきはNIST SP 800-190 多くのセッションにて出てくるコンテナセキュリティを考える上での準拠
こんにちは、テクニカルソリューションアーキテクトの原田です。 普段は、業種業態や技術領域を問わず、様々なお客様の AWS 活用支援を担当しています。 皆さんは「コンテナ」という単語を聞いたことはありますか ? 今日、多くのお客様が本番環境でコンテナを採用し、ビジネスに活かしております。その一方で、「コンテナを使ってみたいけど、コンテナ自体がよく分からない」「何から勉強して良いのかわからない」「なんとなくコンテナを使い始めたけれど、これでいいのか不安」といったコンテナ自体に関するご相談をいただくこともあります。 本記事では、AWS 上でのコンテナの利用方法といった AWS 自体の話からは少し離れて「コンテナ」自体にフォーカスして、そもそもコンテナとは?なぜコンテナか ? (What Containers ? Why Containers ?) についてお話していきます。 今回は、コンテナスペ
本文の内容は、2021年3月9日にÁlvaro Iradierが投稿したブログ(https://sysdig.com/blog/dockerfile-best-practices/)を元に日本語に翻訳・再構成した内容となっております。 Dockerfileのベストプラクティスのクイックセットをイメージビルドに適用することで、セキュリティ問題を防ぎ、コンテナ化されたアプリケーションを最適化する方法を学びます。 コンテナ化されたアプリケーションやマイクロサービスに精通している人なら、自分のサービスがマイクロサービスであることに気づいているかもしれません。しかし、脆弱性の検出、セキュリティ問題の調査、デプロイ後の報告や修正など、管理のオーバーヘッドがマクロな問題になっています。 このオーバーヘッドの多くは、セキュリティをシフトレフトし、開発ワークフローの中で可能な限り早く潜在的な問題に取り組むこ
JX通信社シニア・エンジニア兼データ基盤担当大臣の@shinyorke(しんよーく)です. 最近やった「ちょっとした贅沢」は「休日, 自宅で🍺片手に野球を見ながらUberEatsで注文したランチを楽しむ」です. ⚾と飲食を提供してくださる皆さまに心から感謝しております🙏 JX通信社では, 機械学習を用いたプロダクト開発・施策 プロダクト・サービスの改善に関する分析 日々のイベントをメトリクス化して可視化(いわゆるBI的なもの) を円滑かつ効率よく行うため, 昨年からデータ基盤を整備・運用しており, 現在では社員のみならず(スーパー優秀な)インターンの皆さまと一緒に活用し, 成果を出し始めています. ainow.ai なぜデータ基盤が必要か?どういった事をしているのか?...は上記のインタビューに譲るとして, このエントリーでは「データ基盤を支える技術 - ETL編」と称しまして, Py
Amazon CloudWatch を使用して Amazon ECS リソースモニタリングすることで、Amazon ECSからraw データを収集して、リアルタイムに近い読み取り可能なメトリクスに加工することができます。これらの統計情報は 2 週間単位で記録されるため、履歴情報にアクセスしてクラスターやサービスの動作をより的確に把握できます。Amazon ECS のメトリクスデータは 1 分間隔で自動的に CloudWatch に送信されます。CloudWatch の詳細については、Amazon CloudWatch ユーザーガイドを参照してください。 Amazon ECS は、クラスターとサービスの CloudWatch メトリクスを収集します。CPU およびメモリ使用率など、タスクごとのメトリクスに対して Amazon ECS CloudWatch Container Insights
BusterとかStretchという名前が見慣れない方もいるかもしれませんが、これはLinuxディストリビューションとしてシェアの大きなDebianのコードネームです。 Debianバージョンが少し古いStretchの方がちょびっとサイズが小さかったりはしますが、まあ実用的にはサポートが長い方がいいですよね。slimを使ってGCCとかのコンパイラを自前でダウンロードしている記事とかもたまに見かける気がしますが、マルチステージビルドであれば、そんなにケチケチしなくていいのと、パッケージダウンロードは逐次処理なので遅く、処理系が入ったイメージのダウンロードの方が高速です。並列で処理されるし、一度イメージをダウンロードしてしまえば、なんどもビルドして試すときに効率が良いです。また、多くのケースでネイティブのライブラリも最初から入っており、ビルドでトラブルに遭遇することはかなり減るでしょう。 Py
この記事では、Dockerは触ったことあるけど、k8sみたいなオーケストレーションツールは使ったことないよって人向けに、Dockerのswarm modeでマルチホストなクラスタを構築し、いくつかの代表的な機能(スケールアウトとかローリングアップデートとか)を使うところまでをハンズオン形式で紹介します。 オーケストレーションツール触ってみたいけど、k8sはチョット敷居が高い・・・って人向けです。swarm mode、お手軽でいいよ 今回試す環境は以下のとおりです。 環境 Ubuntu 18.04 LTS 3台 Docker version 18.09.7 docker-compose version 1.24.0 Docker swarm modeとは Dockerのver 1.12以降で組み込まれたオーケストレーションツールです。 これを用いることで、Dockerの機能に加えて、ざっくり
ウェブ・アプリケーションの構築は、安全についての考慮が必要であり、そのために Docker ネットワーク機能を使います。ネットワークとは、定義上、コンテナのために完全な分離(isolation)を提供するものです。そして、アプリケーションの実行にあたり、ネットワーク管理は重要であることを意味します。Docker コンテナ・ネットワークは、これらを管理するものです。 このセクションでは、Docker Engine ドライバ固有の標準ネットワーク機能について、その概要を扱います。ここでは標準のネットワーク・タイプについてと、どのようにして自分自身でユーザ定義ネットワークを使うのかを説明します。また、単一ホストまたはクラスタ上をまたがるホスト間で、ネットワークを作成するために必要なリソースについても説明します。
「これで… これでAWSのコンテナワークロードは、全て、すべて丸見えなんやで… バタッ」 しばらくまえにパブリックプレビューとして提供されていたContainer Insightsですが、ついにGA(一般公開)の運びとなりました!! Container monitoring for Amazon ECS, EKS, and Kubernetes is now available in Amazon CloudWatch 従来のCloudWatchでは取得できなかったタスクやコンテナ単位のメトリクスが、Container Insightsによって取得できます。 さらにGAによって、既存のECSクラスタも追加設定が可能になっており、既に構築済みのクラスタに対して「1分」でContainer Insightsがお手軽に利用できます!!まずは、手元の環境でONにしてもらい、そのメトリクスの便利さ
「Dockerfile書くときによく聞くBGMと好きなワンライナーの発表」 何故かイベント参加フォームにアンケートがあり、それの結果発表が主催のポジティブな Tori(@toricls)さんよりありました。 Dockerfile書くときに好きなBGMは? Docker関連で好きなワンライナーは? 「なんなんだ、この時間は…」と思いながら聞いていると、それはそれはマニアックなこだわりがたくさん。BGMは全体的にアニメやヘビメタが多かった印象。好きなワンライナーは、イメージ一発お掃除系(サブコマンドでイメージ洗い上げるやつとpruneつかうやつ)が主流でした。 「時代はやっぱりpruneだよね。( ・ิω・ิ)」 と謎の盛り上がりをみせ、会場の雰囲気も最高潮! 「環境の一致について考えてみる」 登壇者は、DeNAの春山誠さん(@Spring_MT)。 REREPという新規サービスを開発している
概要 ECSはコンテナのスケールアウトとインスタンスのスケールアウトのタイミングが重要です。 よく起きる問題としては インスタンスのスケールアウトが遅くてコンテナのスケールアウトも遅くなってしまう しきい値が不適切でインスタンスがスケールアウトせず、コンテナがスケールアウトしたくてもできない で、こういった事が起きないようにしないといけません。 スケールアウトの方針 対象 方針 インスタンス インスタンスの空きリソースがコンテナ1台分だけの状態がn分間続いたら コンテナ コンテナの使用率がn%を超えたら インスタンスはもう1台もコンテナを追加するリソースがない状況になったら早めにスケールアウトします。 コンテナは一般的なやり方で使用率が高くなったらスケールアウトすればOKです。 スケールインの方針 対象 方針 インスタンス コンテナがn分間ずっと1台を下回ったら コンテナ コンテナの使用率
インストール Docker エンジンのインストール Mac OS X Windows Ubuntu Red Hat Enterprise Linux CentOS Fedora Debian Arch Linux CRUX Linux FrugalWare Gentoo Oracle Linux openSUSE and SUSE Linux Enterprise Amazon EC2 Google Cloud Platform IBM SoftLayer Microsoft Azure Rackspace Cloud Joyent Triton バイナリをインストール Kitematic のインストール Docker Machine のインストール Docker Compose のインストール Docker Swarm のインストール Docker 基礎 コンテナのクイックスタート Do
dockerを使っていると、コンテナ内の時間がUTCになっていてアレっとなることがよくある。 最初はわざわざdocker build時にtimezoneを設定していたが、ある時/etc/localtimeをvolume mountすればいいじゃないかと気づいた。 docker run -it --rm -v /etc/localtime:/etc/localtime:ro <image> という感じ。これでだいたい満足していたが、ふと検索していたら github.com を見かけた。 まとめるとTZ環境変数を使えということらしい。 $ docker run -it --rm ubuntu:16.04 date Thu Jan 12 13:45:25 UTC 2017 $ docker run -it -e TZ=Asia/Tokyo --rm ubuntu:16.04 date Thu J
結論 以下の手順で作るのが効率的です。 ベースにする Docker イメージを決める docker run -it <docker-image> sh でコンテナ内部で作業 1行ずつ、うまくいったらどこかにメモ 失敗したらいったん exit して再度 docker run ファイルの取り込みやポートの外部公開が必要ならオプション付きで docker run 全部うまくいったら Dockerfile にする ネットで見たことはないですが、もし docker build で試行錯誤しながら Dockerfile を作るとしたら、それはさすがに苦行です。 遅い デバッグしにくい!コンテナ爆発しろ!!って気持ちになります。 これが原因で「Docker 使えない 便利じゃない 」と思っていたのならそれは勘違いです。 手順詳説 試しに ip-api.com にリバースプロキシするだけの Nginx イ
項目ごとにコメントしてみます。 Dockerサポート/AMIの制限 EC2インスタンスでは仮想マシンのroot権が握れるので、AMI(Amazon Machine Image)があれば好みのLinuxディストリビューションにDockerをインストールして利用できます。商用サポートを期待するのであれば、CoreOSやRHEL Atomic Hostを検討するのも良いでしょう。 ECSの場合はECSエージェントを実行していれば任意のディストリビューションで良いようですし、ECSエージェント自体Dockerコンテナで実行するので、ほぼ縛りなしと見なしてよいと思います。一方Beanstalkは、専用AMIからの起動が前提になっているのでディストリビューションはAmazon Linux一択です *1。そもそも「Dockerを利用するモチベーションとしてLinux環境に依存したくない」というのもよくあ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く