DevOps の能力 | Cloud アーキテクチャ センター | Google Cloud
デジタル トランスフォーメーションを加速 お客様がデジタル トランスフォーメーションに乗り出したばかりでも、あるいはすでに進めている場合でも、Google Cloud は困難な課題の解決を支援します。
デジタル トランスフォーメーションを加速 お客様がデジタル トランスフォーメーションに乗り出したばかりでも、あるいはすでに進めている場合でも、Google Cloud は困難な課題の解決を支援します。
世界中のITエンジニアが悩まされている原因不明でテストが失敗する「フレイキーテスト」問題。対策の最新動向をJenkins作者の川口氏が解説（前編）。DevOps Days Tokyo 2022
世界中のITエンジニアが悩まされている原因不明でテストが失敗する「フレイキーテスト」問題。対策の最新動向をJenkins作者の川口氏が解説（前編）。DevOps Days Tokyo 2022 世界中のITエンジニアが悩まされている問題の1つに、テストが原因不明で失敗する、いわゆる「フレイキーテスト」があります。 フレイキーテストは、リトライすると成功することもあるし、失敗する原因を調べようとしてもなかなか分かりません。GoogleやFacebookやGitHub、Spotifyといった先進的な企業でさえもフレイキーテストには悩まされています。 このフレイキーテストにどう立ち向かうべきなのか、Jenkinsの作者として知られる川口耕介氏がその最新動向を伝えるセッション「Flaky test対策の最新動向」を、4月21日、22日の2日間行われたイベント「DevOps Days Tokyo 2
なぜMicroservicesか?
現職においてMonolithアーキテクチャからMicroservicesアーキテクチャへの移行とその基盤の構築に関わって2年近くが経った．未だ道半ばであるがこれまでの経験や日々のインプットをもとにいろいろ書いておこうという気持ちになった．本記事ではそもそもMicroservicesアーキテクチャとは何かを整理し，なぜやるべきか?・なぜ避けるべきかを整理する． Microservices? Microservicesアーキテクチャとは「Single purpose，High cohesion，そしてLoosly Couploedなサービスを組み合わせてシステムを構築する」アーキテクチャ手法である．それぞれの原則をまとめると以下のようになる． Single purpose: 一つのことに集中しておりそれをうまくやること Loose coupling: サービスは依存するサービスについて最小限の
Kubernetesをだいたい理解するまで
インフラ初心者がいきなり実務でKubernetesを使うことになったので、その学習記録✎ 流れとしては、 概念的なところを抑える 実際に手元で動かしてみる です！ また、すでにKubernetesについて書かれたわかりやすい記事がたくさんあるので、本記事はそれらをもとに自分の理解をまとめたものになります。 概念的なこと まずはこれで概要把握 まずは👇を読もう。（ありがたやありがたや...） 僕らは何故Kubernetesを使うのか Kubernetesというものが出てきた背景を、オンプレの時代からどういうふうに変わっていったかわかる KUbernetesの概要がわかる メリデメがわかる Argo CDの例などを用いてどういうふうに使われているのかイメージが付く Kubernetesとは ざっくりいうと、 サービスをコンテナ上で動かすようになったことで起こった、 複数のサーバ上で複数のコン
github.blog GitHub Actions の新バージョンが 8/8 に発表されました。 www.kaizenprogrammer.com 自分は過去にも旧バージョン時に GitHub Actions の入門記事を書いていたのですが、新バージョンがこれまでと大きく変わってしまっているので、この記事ではあらためて GitHub Actions についていろいろ調べたり動かしてみたりした内容をまとめます。 目次 注意事項 GitHub Actions とは これまでの GitHub Actions とどこが変わったか コンセプト マルチプラットフォーム対応 HCL から YAML へ 料金 その他 GitHub Actions と Azure Pipelines 簡単な例 (Hello, World) ワークフローの設定 ワークフローとは ワークフローを実行するイベント ワークフロー
プログラマーがドキュメントを書かない理由
この記事は、著者の許可を得て配信しています。 Why programmers don’t write documentation 最近ではずっとコードのドキュメンテーションに関連した記事を書いていたので、当然、私のMediumのおすすめ記事には「開発者がドキュメントを書かない本当の理由」という記事が表示されるようになりました。この記事では、ドキュメントを書くための優れたツールがないことが、ソフトウェアエンジニアが自分の作業や判断をドキュメンテーションする意欲を失わせる最大の原因について書いています。 私は普段、特定の記事を批判したりはしませんが、この記事には怒りを覚えました。このライターは図解ツールについていくつかメリットに関して述べてはいますが、全体的に誤解を招くような内容になっており、この重要な問題をより分かりにくくさせています。2つの図解ツールを比較して、どちらも不十分なツールである
Google が開発したコンテナ管理システムです。 「クバネティス」「クバネテス」「クーべネティス」などと読まれます。 ギリシャ語で「船長」の意味を持ちます。 Kubernetes のスペルが K と s の間に8文字あることから k8s と表記されることがあります。 Kubernetes を簡略化した k3s というものもあります。 Docker や Podman などに対応しています。 コンテナを Pod と呼ばれる単位で複数のノードに配布して実行管理します。 クライアントからのアクセスを適切にノード上の Pod に転送する仕組みを備えています。 コンテナやノードがダウンしても代わりに他のノードでコンテナを起動してくれます。 サービスを停止することなく、コンテナをローリングアップデートしたりアップデートを中断してロールバックすることができます。 Kubernetes の構築には通常1台
Amazon ECS でのコンテナデプロイの高速化 この記事は同僚の Nathan Peck (@nathanpeck)が書いた記事 “Speeding up Amazon ECS container deployments” を翻訳し、加筆・修正したものです. 元記事を ECS ユーザに紹介する機会が何回かあったので、せっかくなので翻訳することにしました. コンテナのオーケストレーションは非常に複雑な問題の一つです. アプリケーションコンテナのデプロイのために、相互にやり取りを行う複数の異なるコンポーネントが存在します. あなたのアプリケーションを実行したオーケストレータは、その実行されたアプリケーションが Web トラフィックを受け取る用意ができているかどうかについて判断する必要があります. その後そのアプリケーションはスケールダウンされたり、あるいは新しいバージョンのアプリケーション
モダンアプリケーション開発ホワイトペーパー（日本語改定版）が公開されました | Amazon Web Services
Amazon Web Services ブログ モダンアプリケーション開発ホワイトペーパー（日本語改定版）が公開されました 皆さん、こんにちは！ モダンアプリケーション開発スペシャリスト ソリューションアーキテクトの福井です。 私が執筆したモダンアプリケーション開発のホワイトペーパー（日本語版）がAWSホワイトペーパーサイトで公開されましたので、その内容を紹介させて頂きます。このホワイトペーパーは、以前こちらのブログで紹介させて頂いたModern Application Development on AWS（英語版）の日本語版になります。 ホワイトペーパーの内容 公開されたホワイトペーパードキュメントは、「AWS モダンアプリケーション開発 – AWS におけるクラウドネイティブ モダンアプリケーション開発と設計パターン」（日本語版）というタイトルの51ページのドキュメントで、 はじめに
こんにちは。はてなのアプリケーションエンジニアの id:onk です。 最近、若手エンジニアを中心に、いろいろな技術を見つめ直すワーキンググループをやっています。今回は、その中から「デプロイ」の会で発表されたことをまとめました（なお、私は会のとりまとめをやっている非若手です）。 デプロイのライフサイクルの違い Infrastructure Platformでのデプロイ Application Runtime Platformでのデプロイ Applicationsのデプロイ デプロイ方式はどのように変化してきたか In place から Blue/Green へ Immutable Infrastructure という考え方 オートスケールへの対応 push 型デプロイと pull 型デプロイ コンテナによるデプロイの現況 コントロールプレーンによって何が変わったか ECS におけるデプロイ
これまでもコンテナ関連の記事はそれなりに書いてきましたが、改めて最新事情に合わせて練り直したり見渡してみると、大きなところから小さなところまで選択肢が多すぎると感じました。 コンテナ系アーキテクチャを丸っと他所の構成で真似することって、おそらくほとんどなくて、参考にしつつ自分流に築き上げていくでしょうから、今回は築くにあたってどういう選択肢があるのかにフォーカスした変化系で攻めてみようと思った次第です:-) 目次 今年一発目の長いやつです。半分は学習教材用、半分は道楽なテイストです。 はじめに 基盤 インスタンス or コンテナ ECS or EKS on EC2 or FARGATE X86 or ARM64 ロードバランサー メンテナンス：ALB or ECS Service 共有 or １環境毎 アクセスログ：ALB or WEBサーバー ECS / EKS デプロイ：Blue/Gr
この記事は2017/11の以下のブログ記事の翻訳です。 blog.itaysk.com まずはじめに、翻訳を快く許可していただいた@itayskさんに感謝いたします。 3年前の記事ですが、デプロイ戦略についてここまで網羅的にまとめられた記事が日本語で見つけられなかったので翻訳してみようと思いました。 初めての翻訳記事であり、かつ翻訳時に多少の意訳を含んでいます。私の翻訳ミスがある可能性も十分にご了承ください。 何か間違いやわかりにくいところがあれば、コメントいただけますと幸いです。 無謀なデプロイ (Reckless Deployment) ローリングアップグレード (Rolling Upgrade) ヘルスチェックと監視 ロールバック 後方互換性 ちなみに ブルーグリーンデプロイ (Blue/Green Deployment) ドレイン スイッチバック ステージ ちなみに カナリアデプロ
Kubernetesを自動車に載せる、デンソーが「Misaki」を発表。年内にもオープンソースとして公開 自動車部品大手のデンソーは、自動車向けにKubernetesを実行するためのソフトウェア「Misaki」を、6月13日に行われたオンラインイベント「KubeFest Tokyo 2020」で発表しました。 自動車は現在スマート化やネットワーク化が急速に進んでいます。自動運転を目指した自動車の進化を見るまでもなく、今後多くのコンピュータリソースが自動車に搭載されるようになり、そこで実行されるアプリケーションの重要性が高まっていくことは間違いありません。 デンソーが発表した「Misaki」は、このようなアプリケーション実行環境としての自動車をクラウドを中心としたネットワーク化された分散アプリケーション環境のエッジと位置づけ、その基盤をKuberenetesで実現するためのソフトウェアです。
Infrastructure as Dataとは何か
最近GCPから登場したKubernetes YAMLのPackage managerであるKptは「Infrastructure as Data（Configuration as Data）」という考えかたを基礎としてそれを推し進めようとしている．それ以外にもKubernetesのEcosystemには（明示はされていなくても）この考え方が中心にある．Infrastructure as Codeとは何が違うのかなど歴史を振り返りつつまとめてみる． （指針はBorg, Omega, and Kubernetesという論文にあるが「Infrastrcuture as Data（Configuration as Data）」という言葉を明確に定義した文章はない．この記事はReferencesに挙げるいくつかのPodcastにおける@kelseyhightowerの発言や，それに反応する@bgra
リリース手法多すぎﾜﾛﾀｧ B/G、カナリア、機能フラグ、ダークローンチ、A/Bテスト、、など - Qiita
この記事でCloudWatch Evidentlyについて調べていると、「機能フラグ」や「A/Bテスト」などインフラエンジニアには若干聞き慣れないリリース用語が出てきました。 アジャイル開発やCI/CDの台頭に伴い多数出現したこれらのリリース戦略用語をまとめて整理してみることにします。 インフラエンジニアやSREと呼ばれるロールの方々も、リリース戦略を知っておくとCI/CD環境の構築やIaC、はたまたミドルウェアのバージョンアップなどで役立つと思います。 以下ウェブサイトを参考に、各用語を「デプロイ戦略」と「テスト戦略」の大きく2つに分けて紹介します。 デプロイ戦略 従来型のデプロイ（インプレースデプロイ） システム本番環境が一種類のみ存在し、新バージョンの資材デプロイによって旧バージョンの資材を上書いてしまうパターンです。 環境の設計や管理、維持コストをシンプルに抑えられるメリットがあり
GitHubは200万行規模のRailsアプリケーションであり、毎週RailsとRubyを最新版にアップデートし続けている
GitHubは200万行規模のRailsアプリケーションであり、毎週RailsとRubyを最新版にアップデートし続けている 4月10日でサービス開始からちょうど15周年を迎えたGitHubは、当初からRuby on Railsを用いたモノリシックなアプリケーションとして作られてきました。現在では200万行近い規模のコードになっているそうです。 今年1月にはGtHubを利用しているデベロッパーが1億人に到達したことも発表しました。GitHubはまさに世界最大級のRailsアプリケーションだと言っていいでしょう。 そのGitHubは5年前の2018年、Railsのバージョンを3.2から5.2に上げる作業に1年半を費やし。そして二度とこのようなことにならないよう、より頻繁にアップデートを行うべき、などの教訓を得たとしていました。 そして現在、GitHubは毎週月曜日にRailsのアップデート作業
FSE時代におけるWEBサイト制作の研究 #wpshinshu / 2023-05-20 Shinshu WordPress Meetup vol.23
Python コードでアーキテクチャ図を生成できる Diagrams がめっちゃ便利！ - kakakakakku blog
「Diagrams」を使うと Python コードでアーキテクチャ図を生成できる．サポートされているアイコンセットがとても多く AWS や Google Cloud や Microsoft Azure もあれば，Kubernetes やプログラミング言語なども使える．試してみたけどめちゃくちゃ便利！まさに Diagram as Code だ✌️ diagrams.mingrammer.com セットアップ 「Diagrams」は Graphviz に依存しているため，macOS だと pip と brew ですぐにセットアップできる． $ pip install diagrams $ brew install graphviz 試してみた さっそく Examples を参考にアーキテクチャ図を作ってみた！ サンプル : AWS from diagrams import Cluster, D
ECSを触っていて今まで難しいと思ったことを雑にまとめておく。 ECSを仕事で運用するときに必要な知識が多すぎる。こんなの社内に1人AWSマスターいないと無理だ...— 神速 (@sinsoku_listy) 2021年8月10日 タスクロールとタスク実行ロールの違い ECSを長く触っているのに、いつも混乱する。 タスクロール コンテナ内の権限 S3やSESなどの権限をつける タスク実行ロール コンテナ外の権限 ECRやParameter Storeの権限をつける ECSのデプロイ時に静的ファイルが404になる ECSを触った初期に遭遇した。 詳細は以下のQiitaの記事が分かりやすい。 参照: ECSのデプロイ時に一定確率で静的ファイルが404になる問題を回避する 回避する方法はいくつかある。 静的ファイルをS3に置く CodeDeployの OneAtATime を使う CodeDep
メルカリShops の CI/CD と Pull Request 環境 | メルカリエンジニアリング
こんにちは！ソウゾウの Software Engineer の @dragon3 です。 連載：「メルカリShops」プレオープンまでの開発の裏側の８日目を担当させていただきます。 この記事では、メルカリShops 開発において、日々バリバリに利用されている CI/CD 環境と Pull Request 毎のデプロイ環境について紹介します。 CI/CD 環境 メルカリShops では、CI/CD （テスト・ビルド・デプロイ）やその他自動化のために GitHub Actions を使っており、ほとんどのワークフロー・ジョブを Self-hosted runners で実行しています。 Self-hosted runners は、専用の VPC ネットワーク 内の GCE インスタンス上で動かしており、Managed Instance Group 等を使い、そのプロビジョニングや起動・停止等は
Lambdaで動くアプリやフレームワークの事例はよく見るのですが、LambdaのCIやCDにしやすさに主眼をおいた紹介はあんまり見ないので現時点での自分のベストプラクティスのメモです tl;dr; このエントリで書いていること Lambdaをデプロイするのに肝になること デプロイしやすさに着眼したフレームワーク紹介 論外 コンソールからアップロードする できなくはないがかなり厳しい Terraform Apex 8/12 17:20追記 実用レベル Serverless Framework AWS SAM native extension問題と戦う Amazon LinuxのEC2インスタンス内でビルドする Amazon Linux互換のDockerイメージを使う Serverless Frameworkのプラグインを使う ライブラリをインストールするジョブとデプロイするジョブを分ける 【
TechCrunch
Tradeshift, a late-stage fintech startup that has raised over $1 billion in venture and debt, has dismissed its co-founder Christian Lanng, citing “serious allegations of sexual assault and harassme
初めに こんにちは。ビジネスチャットサービスTypetalkを開発・運用している吉田です。Typetalkではデータの永続化ストレージとしてPostgreSQLを利用しています。扱うデータ量は多く、チャットというサービスの性質上書込み頻度はとても高いです。PostgreSQLを使い日々開発を進めていると、追加する機能によってはスキーマを変更する必要があります。メンテナンスを計画・告知してサービスを止めてしまえば、時間はかかるかもしれませんがスキーマの変更はそう難しくありません。しかしTypetalkはユーザーが日々の業務を進めるために利用しており、サービスが止まるとコミュニケーションが取れなくなります。業務を円滑に進めるためのビジネスチャットツールですので、極力サービスは止めたくありません（最後の計画メンテナンスは2019年6月30日で1年以上前となっています。）。本記事では以下の3つのケ
モノレポにすべきか、レポジトリを分割すべきか
先日 フロントエンドの Monorepo をやめてリポジトリ分割したワケ というブログがバズっていた。そのおかげか、Twitter でもモノレポに関する言及がちょこちょこあった。一家言あるドメインなので書きたい。ただの一家言(a.k.a お気持ち)なのでぜひ皆さんの意見も聞いてみたい。 tl;dr 別に自分はどっち派とかではなく、どっちも選ぶ。強いて言うならリポジトリ分割派で、依存更新がしんどくなったら monorepo 派。 免責 モノレポに対する一家言を書きたいだけであって、内容自体はフロントエンドの Monorepo をやめてリポジトリ分割したワケ と全く関係なく、そのブログで述べられている施策については何も言及しません。ただ一つ言及するとしたら肉の部位がコードネームに採用されているのは良いと思いました。🍖🍖🍖 モノレポにしたくなる状態の前提にあるもの 前提は元記事と同じように
songmu @songmu feature branchか、feature flagかっていうのは実は結論のない話なんだろうな、とは思ってる。僕はfeature branchに慣れすぎてしまったけど 2019-10-26 15:32:59 Kazunori Otani @katzchang Gitのリポジトリ/ブランチ戦略で確実に言えそうなのは、「分岐した状態をできるだけ短くしよう」で、それを実現するためにはじつはGitだけの問題じゃなかったりするので、みなさんがんばっていきましょう。 2019-10-26 18:03:42
もうリリースは怖くない ― 大きな変更を安全に本番適用するTips - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、AWS版kintoneのDevOpsエンジニアをしている@ueokandeです。 AWS版kintoneは2019年9月のローンチから現在まで、幾度となく機能改善をしてきました。 ローンチ当時よりも利用者が増え、スケーラビリティのために内部設計を大きく変更することもあります。 先日公開したメール送信の設計変更もその1つです。 blog.cybozu.io 安定運用のために必要なリリースではありますが、実装を大きく変えることで不具合混入のリスクもあります。 それだけではなく、パフォーマンス改善のつもりが、本番環境に投入して逆にパフォーマンス低下が発覚するというケースもあります。 この記事では、大きな変更を安全にリリースするためのTipsを紹介します。 記事の最後ではSpring Bootの実装例と、Kubernetesでの実現方法も紹介します。 切り戻し戦略 大きな変更を安全にリ
Kubernetesは自分にとって必要なのか
この記事は、著者の許可を得て配信しています。 https://mbird.biz/writing/do-i-need-kubernetes.html 私がチームからよく聞かれる質問がこれです。「スタックをKubernetesでホストすべきか」というものです。技術の世界でKubernetesが話題になっていることを考えると、多くの人がそうすべきだと思い込んでいます。 私は数年間k8s（Kubernetes） を使って仕事をしてきました。非常に強力で複雑なプラットフォームを使うことも多々ありました。 ただ真実はもっと微妙だと思っています。 ここでは、その判断をした経緯を紐解いてみたいと思います。スタートアップや、自社製品のホスティングに責任を持つ、より広い組織内の自給自足のチームを対象とした記事となっています。また、大規模な組織の従来のIT部門の人々にも役に立つ記事になっていると思います。 何
こんにちは。ソーシャル経済メディア「NewsPicks」で検索システムを開発しております崔（ちぇ）です。 この記事は、 NewsPicks Advent Calendar 2023 の23日目の記事になります。 qiita.com 昨日ははぐっさんによる「SwiftUIのKeyframeAnimatorでちょっとしたカードアニメーション 〜猫の手を添えて〜」でした！ はじめに コンテナ流儀: 必要最低限のものだけで運用する Point１）レイヤーは少ないほどいい TIP：ベースイメージを作る Point２）不要なパッケージをインストールしない Point３）いつ再起動してもいいコンテナを作る Point４）独立したアプリケーションにする TIP：複数のプロセスを実行したい場合もある TIP：環境変数を積極的に使う Point５）フォアグラウンドで実行する 終わりに まとめ 感想 告知 はじ
リリース頻度を毎週から毎日にしてみた - NTT Communications Engineers' Blog
目次 目次 はじめに NeWork とは リリース頻度変更の背景 それまでの運用 課題 実現方法 解説 日次でワークフローが起動するようにする main ブランチの HEAD にタグが付与されていなければ付与する develop に差分があれば main へのマージを自動で行う 細かな工夫点 main の内容を develop に自動で取り込む 祝日はリリースしないようにする 自動リリース・自動 develop → main マージの制御 Slack にリリース結果を通知する stg 環境に変更内容を通知する その他の考慮 上司への事前説明の省略 スプリントレビュー前のリリース リリースノート 品質面 リリース頻度を変えてみて おわりに はじめに こんにちは、NeWork 開発チームの藤野です。普段はオンラインワークスペースサービス NeWork のエンジニアリングマネジメントをしています
latestタグや書き換えるためのタグ（develop, stagingなど）を使って、本番で運用するのはやめましょう。 コンテナイメージのキャッシュ状況やリリースフローによっては予期しない形で 予期しないバージョンが本番で起動する可能性があります。 本記事では、どのプラットフォームやツールで発生したかについては記載しません。 本題はそこではないのと、そもそも運用が間違っているので 記述しても余計な枝葉になるからです。 この記事ではどういうことが起きたか、について書きます。 どういうことが起きたか サービスで、dockerイメージのlatestタグを使って本番運用していた。 全コンテナをgraceful restartしたようだ。（つもりだったが・・・） 別の作業中、管理画面の表示がおかしくなっているという話が出てきた。 そこで調べてもらったところ、なぜかリリースしたはずの機能が正常に機能
ソフトウェアエンジニアリングサバイバルガイド: 廃墟を直す、廃墟を出る、廃墟を壊す、あるいは廃墟に暮らす、廃墟に死す
ソフトウェアエンジニアリングサバイバルガイド: 廃墟を直す、廃墟を出る、廃墟を壊す、あるいは廃墟に暮らす、廃墟に死す
ひとつのソフトウェアコンポーネントが多くの開発者によって変更されると、品質に悪い影響を与えると経験的に感じている。設計に一貫性が失われることや、知識の浅い状態で変更することによるバグ混入の可能性が高まるからだ。 2011年9月に公開されたマイクロソフト社の調査結果、"Don’t Touch My Code! Examining the Effects of Ownership on Software Quality" は、この「コードのオーナーシップはソフトウェアの品質を左右する」という経験則を裏付けるものだった。全体のコミット数のうち5%未満の貢献にとどまる開発者が多いコンポーネントは、リリース前後における故障が増加するというものだ。 本稿では、このマイクロソフトによる調査結果を紹介し、それを踏まえた上で、ソフトウェアプロダクトの品質悪化を抑えるための組織やプロセス、アーキテクチャについ
New – Use Amazon EC2 Mac Instances to Build & Test macOS, iOS, iPadOS, tvOS, and watchOS Apps | Amazon Web Services
AWS News Blog New – Use Amazon EC2 Mac Instances to Build & Test macOS, iOS, iPadOS, tvOS, and watchOS Apps Throughout the course of my career I have done my best to stay on top of new hardware and software. As a teenager I owned an Altair 8800 and an Apple II. In my first year of college someone gave me a phone number and said “call this with modem.” I did, it answered “PENTAGON TIP,” and I had a
ISUCON運営を支えるAmazon ECSとAurora Serverless v2 / AWS Dev Day 2022 Japan
HashiCorp「Waypoint」発表。環境やプラットフォームの違いを吸収してコマンド一発でビルド、デプロイ、リリースを実行
HashiCorp「Waypoint」発表。環境やプラットフォームの違いを吸収してコマンド一発でビルド、デプロイ、リリースを実行 HashiCorpは新しいオープンソースプロジェクト「Waypoint」を発表しました。 Introducing HashiCorp Waypoint, a new open source project providing consistent developer workflows to build, deploy, and release applications across any platform #HashiConf #WaypointUp Learn more: https://t.co/l1LPgph9tA pic.twitter.com/PoSIrz4xXo — HashiCorp (@HashiCorp) October 15, 2020
令和時代のRails運用
https://shuuu-mai.connpass.com/event/173794/
GitHub Actions now supports CI/CD, free for public repositories
CompanyProductGitHub Actions now supports CI/CD, free for public repositoriesSince we introduced GitHub Actions last year, the response has been phenomenal, and developers have created thousands of inspired workflows. But we’ve also heard clear feedback from almost everyone: you want CI/CD! And that’s what we’re announcing today. GitHub Actions is an API for cause and effect on GitHub: orchestrate
あなたの組織に最適なコンテナデプロイ方法とは？〜ECSにおけるデプロイ最新機能てんこ盛り〜
AWSにおけるコンテナワークロード運用のデファクトスタンダードの地位を確立したECS。 デプロイ方法も進化を続け、CodeDeployとALBで連携したB/Gデプロイやカナリアリリースにも対応し、そのデプロイにおける柔軟性はEKSに勝るとも劣りません。 そんなECSですが、手段が豊富になったこともあり現状「そもそもうちの組織としてどんなデプロイ方法が最適なのか？」を選択するのが難しくなっています。 このセッションでは、ECSのデプロイ機能を紹介しつつ、マルチアカウントでの運用、リリース承認プロセス、IaCとの連携方法、GitHub Actionsも含めた最新動向を全てお伝えいたします。
こんにちは。こむろです。 今年の札幌の夏はハードモードだ（湿気と暑さ） この先生きのこるためにエアコンが投入されました。 はじめに クラウドネイティブなアプリケーションを設計・構築・運用している皆さんは、普段どのようにアプリケーションやインフラの更新作業を行っているでしょうか。 順次インスタンスやコンテナを切り替えていくRolling Update？それとも環境を複製してDNS Routingの切り替えによるBlue-Green Deploymentでしょうか。他にも様々な方法があるかと思いますが、今回もまたBlue-Green Deploymentにおける実際の現場で発生した事象について報告したいと思います。 あまりネット上にもこういった情報が出てこないようなのですが、皆さんこういった問題は軽々とクリアされているのでしょうか。自分がポンコツなだけなのかととても不安にかられるばかりです。
Amazon ECSで好きなだけ検証環境を起動できるOSSの設計・実装・運用 / YAPC::Hiroshima 2024
https://fortee.jp/yapc-hiroshima-2024/proposal/1e9fbacd-5a50-43ef-87f1-490e85448f17
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
新 GitHub Actions 入門 - 生産性向上ブログ
とほほのKubernetes入門 - とほほのWWW入門
Amazon ECS でのコンテナデプロイの高速化
デプロイ今昔 - Hatena Developer Blog
AWSコンテナ系アーキテクチャの選択肢を最適化する | 外道父の匠
【翻訳記事】デプロイ戦略の定義 - そこに仁義はあるのか(仮)
Kubernetesを自動車に載せる、デンソーが「Misaki」を発表。年内にもオープンソースとして公開
フロントエンドエンジニアのためのAWSアーキテクチャ
ECSを運用で使っていて難しいと思った点 - アジャイルSEの憂鬱
AWS Lambda CI/CD俺的ベストプラクティス - くりにっき
運用中のPostgreSQLのスキーマを無停止で安全に変更する | 株式会社ヌーラボ(Nulab inc.)
git の develop ブランチは必要なのか、またはリリースtagについて
ジュニアエンジニアを脱却するための「コンテナ流儀」 - Uzabase for Engineers
latestタグのままdocker imageを本番運用してどうなったか - 京都行きたい
マイクロソフトの調査にみるコードのオーナーシップと品質の関係 - mtx2s’s blog
Webサービスを1日10回デプロイするための取り組み / SRE NEXT 2020
Blue-Green Deploymentにおける注意点 | DevelopersIO
www.maplefarm.jp
doanakirakoga.hatenablog.com
femimatsu.com
orion12.hatenablog.com
kikenbutsuhawthorne97.hatenablog.com
altobenri.seesaa.net