Run Locally, Deploy GloballyDevelop and test your AWS applications locally to reduce development time and increase product velocity. Reduce unnecessary AWS spend and remove the complexity and risk of maintaining AWS dev accounts.
AWSのインフラ管理はIaC? いやちゃうちゃう。時代はInfrastructure as SQL (IaSQL)でしょAWSPostgreSQLIaCQiitaEngineerFesta2022IaSQL 概要 皆さんAWSのインフラ管理どうしてますか? なるべくならインフラ管理は自動化。手順書も作らず、資源作成時誰でもどの環境に対し同じものを作成したいですよね。 そんな時、Infrastructure as Code(IaC)を採用し、インフラ管理をコード化するのは当たり前になってきているんじゃないでしょうか。 AWSにおけるIaCだと例えば、Cloudformationとか、AWS CDKとかTerraform等、様々です。 ただ今回は、そんなIaCの紹介・・・ではなく、全く新しい概念のInfrastructure as SQL (IaSQL) なるものについて、ご紹介したいと思いま
Close the gap from production to development through automated environments on Kubernetes Transform development for your companyYour developers should be focused on innovation and writing code, not navigating the complexities of cloud native environments. With Okteto, platform engineering can automate building, provisioning and managing production-like environments with everything a developer need
こんにちは、LayerX で主にインフラを担当している高江です。 今回は、一見地味ではありますが実はとても役に立つ機能である Terraform import についてお話したいと思います。 Terraform import とは 公式サイトでは次のように説明されています。 Terraform is able to import existing infrastructure. This allows you take resources you've created by some other means and bring it under Terraform management. 要するに、AWS 等のサービスプロバイダー上に既に存在する、Terraform 管理されていないリソースの情報を取得して Terraform 管理下に置く(tfstate ファイルに import する)
DevOpsDays Tokyo 2021 で使用したスライドです。 Infrastructure as Code を導入してみたはいいけれど、デプロイしてみたらなぜか上手く動かない。そんな経験はありませんか? 本セッションでは、実際の環境を構築する「前」に、IaC のコード自体に対してテストを行う手法について解説します。 ご存知の通り Infrastructure as Code (IaC) は、インフラをコードで定義することを通し、アプリケーション開発のベストプラクティスをインフラ領域にも輸入しようとする方法論です。IaC の考え方は近年急速に普及し、開発フローの一部として種々の IaC ツールを利用することは半ば常識のような状態にあります。 しかし同時に、IaC は銀の弾丸ではありません。特に組織的な導入を考えようとすると、得てして「なぜか上手くいかない」「余計に運用が辛くなってしま
data "aws_caller_identity" "current" {} output "account_id" { value = data.aws_caller_identity.current.account_id } 若干補足しておくと、 "${}" 自体が廃止されたわけではなく、今でも文字列の中に変数を埋め込む場合には必要ですが、式が変数の参照しか含まない場合は不要で、v0.13.4以降は冗長な書き方は警告が出ます。ちなみにv0.14のfmtはもう一歩踏み込んで、この書き方を自動で修正するようになりました。古いサンプルコードを雑にコピペできるようになってべんり。 Terraformではなく汎用的なHCLそのものの仕様を調べたいときは、 hashicorp/hcl にありますが、本稿執筆時点ではデフォルトのmasterブランチはまだHCL1であることに注意して下さい。 HCL
最近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
Cloud Native Buildpacks (CNBs) transform your application source code into container images that can run on any cloud. With buildpacks, organizations can concentrate the knowledge of container build best practices within a specialized team, instead of having application developers across the organization individually maintain their own Dockerfiles. This makes it easier to know what is inside appli
今年読んだ技術書籍やレポートなどをざっくりまとめてる.Infrastructure Engineer・Platfomerとして日々の業務に直結するものから1年くらいかけてやっていきたいと思っていることなどを中心に. Kubernetes 業務ではメインにKubernetesを使っているのでKubernetesに関わる書籍は発売されれば大体目を通すようにしている. 今年発売されたので良かったのはProgramming Kubernetes.この本はCRDやOperatorによってKubernetes nativeなアプリケーションを構築することにフォーカスしている.昨年のJapanContainerDaysでのMicroservices Platform on Kubernetes at Mercariでも話したようにKubernetesを使う大きな理由の1つはその拡張性にある.Kubebu
「Pulumi」がバージョン1.0に到達、正式版に。インフラの状態をJavaScript、Python、Goなどで記述可能。個人向けサービスは無料で提供 かつてサーバの設定や起動、ネットワークの構成といったインフラの構築は、それぞれの設定ツールやコンソールから運用担当者がマニュアル操作で行ってきました(いまでもそうしている組織は少なくないでしょう)。 しかし仮想化基盤やクラウドなど最近のモダンなインフラでは、APIや設定ファイルを通じてプロビジョニングやコンフィグレーションが可能です。 このようにソフトウェアでインフラの状態の表現が可能になることを、いわゆる「Infrastructure as Code」(コードとしてのインフラ)と呼びます。 Infrastructure as Codeの利点は、インフラの状態をコードで記述することによって、誰でも確実に間違いなく実行できて手作業によるミス
ssmjp 2019/03での発表資料です。 「運用自動化の基本原則」シリーズの番外編と位置付けています。 # 運用自動化の基本原則シリーズ - 2019-03-06 「運用自動化」とは: https://speakerdeck.com/opelab/20190306-operation-what-automation - 2019-05-24 運用業務の「構造化」: https://speakerdeck.com/opelab/20190524-structured-operation - 2019-04-18 運用自動化の基本原則1 「引継ぎの原則」: https://speakerdeck.com/opelab/20190418-operation-automation-basis-principle-1 - 2019-05-24 運用自動化の基本原則2「平易化の原則」: https
ChatGPT関連情報の追い方、個人・業務での使い方、サービスへの組み込み方、 ABEJAでの取り組み4例、ここ2週間のトピックなど行けるところまで
次世代 Web カンファレンスで監視について話すことになったので、ネタとしてWEB系各社で使っている監視ツールを調査中。 うちはこれ使ってるよ!!!ってのがあったら@mikedaにメンションください! Cookpad Zabbix 昔はNagios+muninだけど台数増えて性能的に破綻した ビューはそのままじゃ辛いのでmunin風に表示するのを自作 StatusCake DataDog。サービス系、サーバに紐付かない系の監視に。DashBoard便利 waker。通知用。PagerDuty高い、と言ってryot_a_raiが秒で作ったらしい Kibana imon。独自のリアルタイムなサービス稼働状況表示ツール NewRelic 試し中なもの Real-User Monitoring : JSでbeacon飛ばしてfluentd -> BigQuery。Google SpreadShee
事前に断っておくがここでいう「インフラ」はレイヤ的には OS より上の話。 少し前に GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー で、GitHub を介したデプロイを実践しているということを紹介した。普段の開発を Pull Request ベースでやっているので、デプロイもまた Pull Request を契機に実行させると色々捗る、という話。 このプラクティスの対象領域をインフラにまで拡大してみました、というのが今回の話。 DNS レコードを Pull Request を merge した契機に自動で更新 AWS を利用している場合、ドメインの管理も Amazon Route 53 を使うといろいろと都合がいい。 Route 53 での DNS レコードの更新はこれまでブラウザから操作していた。これだと誰がいつ作業したかわからないし履歴もトラックしづらい。また変更
2014年08月04日11:11 インフラ Ansibleを使って誰でも簡単安全にサーバ構築できる仕組みを作る Ansible って何なの? サーバに対してミドルウェアのインストールや設定等の環境構築を行うことをプロビジョニングと言いますが、その作業を自動化させるためのツールです。プロビジョニングを手動で行うと、手間も掛かるし、どうしてもミスが起こりえます。 その点、Ansible のようなツールを使えば、コマンド一発でプロビジョニングが走り、さらに冪等性(何度実行しても同じ結果になる)も確保されるため、誰でも簡単安全にサーバ構築が出来るのです。 同様のことを行うツールとして、Chef や Puppet がありますが、Ansible はそれらの中でもシンプルなことが特徴です。Chef は以前使ってみようと思い触ってみたのですが、覚えることが多かったりして挫折してしまった。。Ansible
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く