障害対応からOSSへコントリビューションを行った時の話
Pulling xxxxxxxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/xxxxx:latest (attempt 3 of 3)... Error response from daemon: Get https://xxxxxxxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/v2/: dial tcp: lookup xxxxxxxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com on 172.18.0.3:53: read udp 10.254.0.122:48372->172.18.0.3:53: i/o timeout デプロイまでのフローは ボタンクリックすると、 git clone -> docker build -> docker push -> k8
コンテナ未経験新人が学ぶコンテナ技術入門
最近勉強を始めたコンテナ技術に関する基礎的な知識をまとめました。 [訂正と注釈] 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
［速報］Google、新プラットフォーム「Cloud Services Platform」発表。Kubernetes、Istio、Apigeeなど統合しコンテナアプリケーション基盤に最適化。Go...
Googleは、コンテナアプリケーションの実行と運用に最適化した新しいクラウドプラットフォーム「Cloud Services Platform」を、サンフランシスコで開幕した同社のイベント「Google Cloud Next '18」で発表しました。 Google Cloud Next '18の基調講演でCloud Services Platformを発表するGoogle Technical Infrastructure SVP、Urs Hölzle氏 Announcing Cloud Services Platform, an integrated family of cloud services across GCP and on-premise environments that bring the benefits of the cloud to you, no matter wh
［速報］Google、コンテナ実行環境をサーバレスで提供する「Serverless containers」発表。Google Cloud Next '18 － Publickey
［速報］Google、コンテナ実行環境をサーバレスで提供する「Serverless containers」発表。Google Cloud Next '18 Googleはサーバのプロビジョニングやオートスケールなどサーバの運用管理などを意識することなく、コンテナ化したアプリケーションの実行を可能にする新サービス「Serverless containers」を発表しました。 #Serverless announcements coming your way: New App Engine Runtimes: Python 3.7 & Standard PHP 7.2 Cloud Functions GA Serverless containers GKE Serverless add-on Knative Cloud Build https://t.co/1fW7feKEfz #Google
Amazon ECS にデーモンスケジューリングが追加
Amazon Elastic Container Service (Amazon ECS) は今回、新しいデーモンスケジューリングストラテジーを導入し、ECS クラスター内で選択したインスタンスセット内のインスタンスすべてに対してデーモンタスクを自動で実行できるようになります。 デーモンタスクとは、ロギング、モニタリング、またはアプリケーションコードを実行するタスクのバックアップのような共通サポート機能を付与するために、クラスター内のそれぞれのインスタンスにタスクがデプロイされたマイクロサービスをビルドするときに使用されるパターンのことです。 これまでは、これらを確保するために、デーモンタスクは Auto Scaling テンプレートに結び付いた複雑なスクリプトの実行を要するクラスター内のインスタンスセットにデプロイされていました。ユーザーは代わりに各アプリケーションタスクの一部としてデー
Visual StudioがKubernetes対応。DockerfileとHelmチャートを自動生成し、Kubernetes環境へデプロイ可能に
Visual StudioがKubernetes対応。DockerfileとHelmチャートを自動生成し、Kubernetes環境へデプロイ可能に マイクロソフトは、Visual Studioを用いてKubernetesに対するアプリケーション展開を容易にするツール群「Visual Studio Kubernetes Tools」のプレビュー版を公開しました。 Visual Studio Kubernetes Toolsを用いることでKubernetes環境へのデプロイに必要な設定ファイルを自動生成し、すぐにデプロイできるようになります。 DockerfileとHelmチャートを自動生成するVisual Studio Kubernetes Tools Visual Studio Kubernetes Toolsをインストールすると、Kubernetes対応のアプリケーションを開発するプロジ
Amazon EKS – Now Generally Available | Amazon Web Services
AWS News Blog Amazon EKS – Now Generally Available We announced Amazon Elastic Kubernetes Service (EKS) and invited customers to take a look at a preview during re:Invent 2017. Today I am pleased to be able to let you know that EKS is available for use in production form. It has been certified as Kubernetes conformant, and is ready to run your existing Kubernetes workloads. Based on the most recen
Amazon ECSとKubernetesの統合サービスディスカバリー | Amazon Web Services
Amazon Web Services ブログ Amazon ECSとKubernetesの統合サービスディスカバリー 本日（訳注：2018年5月31日）から、Amazon Elastic Container Service（Amazon ECS）およびKubernetesによって管理されるサービスの統合サービスディスカバリーを活用することができます。私たちは最近、Amazon Route 53 Auto Naming（オートネーミング）APIを使用してサービス名のレジストリを作成および管理することにより、コンテナ化されたサービスの発見と相互接続を容易にするECSサービスディスカバリーを導入しました。サービス名は、一連のDNSレコードセットに自動的にマップされます。これにより、コード内でサービスを名前（backend.example.comなど）で参照可能となり、実行時にサービスのエンドポ
Running AWS Fargate with virtual-kubelet | Amazon Web Services
AWS Open Source Blog Running AWS Fargate with virtual-kubelet 中文版 AWS Fargate is a new compute engine that allows you to run containers without having to provision, manage, or scale servers. Today, Fargate is natively integrated with Amazon Elastic Container Service (ECS). Since we announced Fargate at re:Invent 2017, many customers have told us that they were very interested in using Fargate to r
『コンテナ疲れ』と戦う、k8s・PaaS・Serverlessの活用法
Kubernetes 疲れに Azure Container Apps はいかがでしょうか？（江東区合同ライトニングトーク 発表資料）
Kubernetes活用に至るまで――リクルートテクノロジーズがコンテナを大規模システムの本番環境へ適用した事例
Kubernetes活用に至るまで――リクルートテクノロジーズがコンテナを大規模システムの本番環境へ適用した事例：先行事例に学ぶKubernetes企業活用の現実（2） 本連載では、サービスの開発、提供のアジリティ向上の一助となることを目的として、企業における「Kubernetes」の活用について解説する。今回は、リクルートテクノロジーズにおいて筆者が取り組んだ事例を基に、コンテナ仮想化技術を本番環境で利用する際の取り組み、成果と課題、「なぜ最終的にKubernetesを活用する決断に至ったか」を説明する。 コンテナ仮想化技術を本番環境で利用する際の3つのフェーズ 昨今、コンテナオーケストレーションツール「Kubernetes」に注目が集まっています。本連載「先行事例に学ぶKubernetes企業活用の現実」では、サービスの開発、提供のアジリティー向上の一助となることを目的として、企業にお
GitLab 10.4リリース。WebIDE搭載開始、Dockerイメージの静的セキュリティ解析、アプリケーションの動的セキュリティテストなどの新機能
GitLab 10.4では、デプロイ前のDockerイメージに対して静的セキュリティ解析を行うツールや、動的にセキュリティ解析を行うツール、そしてWebブラウザから利用できる統合開発ツールなどが搭載された。 主な新機能として、アプリケーションをDockerコンテナとしてパッケージしたあとで静的セキュリティ解析を行う「Static Application Security Testing (SAST) for Docker Containers」、Webアプリケーションに対して動的なセキュリティテストが可能な「Dynamic Application Security Testing (DAST)」、そしてWebブラウザでコードを編集できるWebIDE機能などが搭載されました。 clairを用いてコンテナの静的解析 GitLabには、コードの静的解析を行う「Code Quality」機能がすで
Kubernetes を利用したコンテナベース機械学習基盤の構築 - LIVESENSE Data Analytics Blog
データプラットフォームチームの野本です。機械学習基盤の構築やその周辺アプリケーションの実装を行っています。以前は DOOR 賃貸の開発運用をしていてこんなことなどしてました。 機械学習システム運用の課題 リブセンスでは 2014 年ごろから機械学習システムの開発導入を行っており以降様々な機械学習システムを各サービスに導入してきました。また自社でのデータ分析基盤の運用も行うようになってから機械学習システムの開発の幅が広がり導入の要望も次第に増えてきました。(参考:リブセンスのデータ専門組織のこれまでとこれから) 当初は機械学習システムに対する運用知見などが少なかったため、専用のインフラというものは保持せず各サービスのインフラに相乗りし、サービスのアプリケーションと密に連携し機械学習システムを実装運用することが多かったです。各サービスは元々オンプレミスで運用されていたものが多かったのですが、現
AWS Fargateの紹介 – インフラストラクチャの管理不要でコンテナを起動 | Amazon Web Services
Amazon Web Services ブログ AWS Fargateの紹介 – インフラストラクチャの管理不要でコンテナを起動 コンテナは、開発者がアプリケーションを開発・パッケージ・デプロイするのに強力な手法の１つです。AWSでは、十万以上のアクティブなECSクラスタが稼働しており、毎週数億の新しいコンテナが起動しています。これは、2016年からすると400%を超えるお客様成長率です。Amazon ECSやKubernetesといったコンテナのオーケストレーションソリューションは、コンテナワークロードのデプロイ・管理・スケールをより容易にし、敏捷性を増します。しかし、それらのどのソリューションも下回りとなるインフラストラクチャの可用性、キャパシティやメンテナンスを行う必要が依然としてあります。AWSにおいて、私たちはこれを差別化とならない重労働を取り除く機会と考えました。私たちは、コン
ECSのオートスケール戦略 - Carpe Diem
概要 ECSはコンテナのスケールアウトとインスタンスのスケールアウトのタイミングが重要です。 よく起きる問題としては インスタンスのスケールアウトが遅くてコンテナのスケールアウトも遅くなってしまう しきい値が不適切でインスタンスがスケールアウトせず、コンテナがスケールアウトしたくてもできない で、こういった事が起きないようにしないといけません。 スケールアウトの方針 対象 方針 インスタンス インスタンスの空きリソースがコンテナ１台分だけの状態がｎ分間続いたら コンテナ コンテナの使用率がｎ%を超えたら インスタンスはもう１台もコンテナを追加するリソースがない状況になったら早めにスケールアウトします。 コンテナは一般的なやり方で使用率が高くなったらスケールアウトすればOKです。 スケールインの方針 対象 方針 インスタンス コンテナがｎ分間ずっと１台を下回ったら コンテナ コンテナの使用率
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AWS Savings Plans: New AWS cost management feature | Hacker News
20分でわかるgVisor入門
Container Networking Deep Dive
JapanContainerDays v18.12
Kubernetesの事始め
