CloudFormation Fn::Cidr の実行例 - Qiita
--- AWSTemplateFormatVersion: '2010-09-09' Description: 'Amazon EKS Sample VPC' Parameters: VpcBlock: Type: String Default: 192.168.0.0/16 Description: The CIDR range for the VPC. This should be a valid private (RFC 1918) CIDR range. Resources: VPC: Type: AWS::EC2::VPC Properties: CidrBlock: !Ref VpcBlock EnableDnsSupport: true EnableDnsHostnames: true Outputs: Subnets: Description: Output Fn::Cid
今更ながら、CloudFormation で ElastiCache を構築した。 - Qiita
はじめに ElastiCache を使いたいって話が出たので、コンソールからポチポチ作ろうと思ったんです。 どうせならと思い、CloudFormation を使ってデプロイできるようにすれば、何回も同じことしなくてもいいっしょ、てな考えから作ってみました。 やってみた 作るもの Memcached(Multi AZ) Redis Cluster テンプレート JSON は人が書くものじゃないと思っているので、yaml で。初めて作ったんでこんなもんでしょ。 VPC とサブネットは作成済みだったんで、ID を指定しているだけです。 AWSTemplateFormatVersion: 2010-09-09 Parameters: Subnet1: Type: String Default: [ゾーンAのサブネットID] Subnet2: Type: String Default: [ゾーンCの
データをテーブルにインサートされると、バーチジョブが実行される(cfn) - Qiita
目的 以下のRDS->lambda->AWSbatchという流れで実行したい 実現したいのはデータをテーブルにインサートしたら INSERT INTO batch_order_data VALUES (NULL, 'item_001'); 結果：hello worldなどpythonのスクリプトが実行される。 前提条件 （追加の手順があるため、必須ではない） ECR URLが既にあること以下の図だとpipeline1で作られていた。 ci/cdのやり方だとpipeline1とpipeline2も事前にあること しかしci/cdでなくても、実現できるので必須ではありません。 手順 1.事前にContainerImageを準備する必要があります。 dockerfileでcicd デプロイする方は以下のdockerfileをご参考に //もととなるコンテナイメージをpull $ docker p
CloudFormationを使ってVPCを構築する - Qiita
AWSTemplateFormatVersion: "2010-09-09" Description: VPC and Subnet Create Metadata: "AWS::CloudFormation::Interface": ParameterGroups: - Label: default: "Project Name Prefix" Parameters: - PJPrefix - Label: default: "Network Configuration" Parameters: - VPCCIDR - PublicSubnetACIDR - PublicSubnetCCIDR - PrivateSubnetACIDR - PrivateSubnetCCIDR ParameterLabels: VPCCIDR: default: "VPC CIDR" PublicSubn
CloudFormationを使ってNAT Gatewayを構築する - Qiita
AWSTemplateFormatVersion: "2010-09-09" Description: NAT Gateway Create Metadata: "AWS::CloudFormation::Interface": ParameterGroups: - Label: default: "Project Name Prefix" Parameters: - PJPrefix - Label: default: "NATGateway Configuration" Parameters: - NATGatewayACreate - NATGatewayCCreate ParameterLabels: NATGatewayACreate: default: "NATGatewayACreate" NATGatewayCCreate: default: "NATGatewayCCre
CloudFormationを使ってVPCフローログを設定する - Qiita
はじめに 本記事では、AWS CloudFormation管理コンソールを使って、VPCフローログを設定する手順を説明しています。（初心者向け） 本記事で掲載しているテンプレートの最新版は、下記に置いてます。 https://github.com/okubo-t/aws-cloudformation 出力先をS3に設定する手順は、下記を参照して下さい。 CloudFormationを使ってVPCフローログを設定し出力先をS3に設定する [https://qiita.com/okubot55/items/fbb1ae40bd8104958102] 構成図 前提条件 下記の記事の構築手順で、VPCを構築していること。 [CloudFormationを使ってVPCを構築する] (https://qiita.com/okubot55/items/b18a5dd5166f1ec2696c) PJPr
CloudFormationを使って最新のAmazonLinuxのAMIでEC2を構築する - Qiita
AWSTemplateFormatVersion: "2010-09-09" Description: EC2 Instance Create Metadata: "AWS::CloudFormation::Interface": ParameterGroups: - Label: default: "Project Name Prefix" Parameters: - PJPrefix - Label: default: "EC2Instance Configuration" Parameters: - KeyPairName - EC2InstanceName - EC2InstanceAMI - EC2InstanceInstanceType - EC2InstanceVolumeType - EC2InstanceVolumeSize - EC2InstanceSubnet - S
CloudFormationでIAMユーザ、IAMグループ、IAMロール、IAMポリシーを作成するための基礎知識おさらい - Qiita
はじめに 最近IAMに触り始め、CloudFormationでIAM系リソース作成する為の設計を始めた しかし、ルートアカウント、IAMユーザー、IAMロール、IAMグループ、IAMポリシーなど扱う要素が多く、それぞれの関係性がわかりづらく、設計が難航した 取り急ぎCloudFormation開発が進められるようにしたかったので、何番煎じかわからないが、IAMについて改めてまとめた 想定読者 CloudFormation：テンプレートを書いて実行したことがある IAM：触り始めたくらい この記事が目指すゴール CloudFormationによるIAMリソース作成の設計をする為の事前知識を、記事を読めばざっくりおさらいできる それぞれの項目について、どのドキュメントをあたればいいか、ユーザードキュメントへのリンクで飛べる 調べた内容 IAMとは IAM(Identity and Access
HerokuでRedmineをデプロイ（までの長い道のり） - Qiita
2016/10/10にリリースされた 3.3.1 をHerokuにデプロイして利用できるようにする。 しかしこれがわりとハマるところが多かった… 前例多いけど、わりと環境にも依存するので なかなか一筋縄でいかない感じが（ そしてまだリアルタイム作業中だよ！よ！ そもそもなぜHerokuを選んだか みなさんいろんな観点で選定すると思うんですよ。 クラウド使う人が多いとは思う。 今回はこういう観点で選定してみまんた。 自前でリソース準備しなくても良い（=PaaS含めクラウドのメリット） 初期構築コストが（IaaSほど）かからない IaaSの場合：OSにも左右されるのでライブラリの依存関係もわりとシビアに考えないといけなかったり Ruby、Java、Python、Scalaなど複数言語とフレームワークをサポート 基本的な機能は無料枠で利用できる。お財布に優しい Gitを使ってデプロイ Gitに慣
Docker上でAnacondaを使って入れたDjangoをHerokuで動かす - Qiita
#はじめに 1.Djangoを触ってみようと思った 2.pythonのパッケージ管理は全部anacondaのcondaでやりたい 3.Dockerで環境を分けるのでcondaで仮想環境とかは用意しない 4.ローカルの開発環境も本番環境もDockerでやりたい 5.Djangoの入門におすすめらしいDjango GirlsのTutorialを動かす前提でやる 6.本番環境はDjango GirlsのTutorialに従ってHerokuに公開する こんな感じの方針でHeroku上でDockerを動かし、そこでAnaconda経由で入れたDjangoを動かす環境の用意の仕方をまとめます。 ※※※※※ 普段Djangoどころかサーバーサイドのプログラムをしない素人のまとめです。 Dockerも触り始めたばかりでもっと効率良い仕組みもある気がしてます。 何かこうした方がいいとかあればぜひ教えてくださ
[Ruby] RailsをHerokuへデプロイする時の７つの注意事項 [Heroku] - Qiita
先日、Ruby開発者のためのHeroku入門というWebセミナーを行いました。この時の内容の振り返りとしての、注意事項の補足説明です。 元のスライドはRuby開発者のためのHeroku入門を御覧ください デプロイ前の注意事項 デプロイする前、アプリケーションを開発する時に考慮しておくべき事項 5つを紹介します 1. データベースサーバの選定について Heroku では、RDBMS は Heroku Postgresを、高速なKVSの場合には Heroku Redisを推奨することが一般的です。純粋に、Herokuが提供しているアドオンだからということと、Heroku Postgresに限っては、常に最新版を利用することができることも、推奨するポイントです。 もちろん、MySQL や Mongo、Cassandraなど、3rd Vendorの提供するデータベースを利用することも可能ですが、H
![[Ruby] RailsをHerokuへデプロイする時の７つの注意事項 [Heroku] - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/74fb8153eabc9112bcf594da60ab8aca37dd7c0d/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fqiita-user-contents.imgix.net%252Fhttps%25253A%25252F%25252Fcdn.qiita.com%25252Fassets%25252Fpublic%25252Farticle-ogp-background-afbab5eb44e0b055cce1258705637a91.png%253Fixlib%253Drb-4.0.0%2526w%253D1200%2526blend64%253DaHR0cHM6Ly9xaWl0YS11c2VyLXByb2ZpbGUtaW1hZ2VzLmltZ2l4Lm5ldC9odHRwcyUzQSUyRiUyRnFpaXRhLWltYWdlLXN0b3JlLnMzLmFtYXpvbmF3cy5jb20lMkYwJTJGMzcyNjMlMkZwcm9maWxlLWltYWdlcyUyRjE1MTQ0NDYzMDA_aXhsaWI9cmItNC4wLjAmYXI9MSUzQTEmZml0PWNyb3AmbWFzaz1lbGxpcHNlJmZtPXBuZzMyJnM9NjZiMDQ0NWY2YTI5MDFjZjA1ZjY1ZDFiYWIzYzNmMGM%2526blend-x%253D120%2526blend-y%253D467%2526blend-w%253D82%2526blend-h%253D82%2526blend-mode%253Dnormal%2526s%253D5416e92f8f52f41915d863924b4abf36%3Fixlib%3Drb-4.0.0%26w%3D1200%26fm%3Djpg%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk2MCZoPTMyNCZ0eHQ9JTVCUnVieSU1RCUyMFJhaWxzJUUzJTgyJTkySGVyb2t1JUUzJTgxJUI4JUUzJTgzJTg3JUUzJTgzJTk3JUUzJTgzJUFEJUUzJTgyJUE0JUUzJTgxJTk5JUUzJTgyJThCJUU2JTk5JTgyJUUzJTgxJUFFJUVGJUJDJTk3JUUzJTgxJUE0JUUzJTgxJUFFJUU2JUIzJUE4JUU2JTg0JThGJUU0JUJBJThCJUU5JUEwJTg1JTIwJTVCSGVyb2t1JTVEJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMxRTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LXBhZD0wJnM9Y2U1ZWU1ZDNhZTVmMDNhYWRjNjBiOWNlMDNkOWEyNDA%26mark-x%3D120%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTgzOCZoPTU4JnR4dD0lNDBzaG83NjUwJnR4dC1jb2xvcj0lMjMxRTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LXBhZD0wJnM9ZDBiOTg1MGQ0MzVmY2QxZjM5NTQwYWI3Zjc3ZTBjYTE%26blend-x%3D242%26blend-y%3D480%26blend-w%3D838%26blend-h%3D46%26blend-fit%3Dcrop%26blend-crop%3Dleft%252Cbottom%26blend-mode%3Dnormal%26s%3D5774f3415feb1f2d572cd423c8c06543)
(デプロイ編①)世界一丁寧なAWS解説。EC2を利用して、RailsアプリをAWSにあげるまで - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 本記事は2021年版にアップデートされ、下記URLに移転いたしました。 https://zenn.dev/naoki_mochizuki/books/1471ce20222227 本記事では、アップデートされた記事の冒頭部分を抜粋して記載させていただきます。 =====以下、記事抜粋部分===== それでは、いよいよAWSアカウントにログインして作業を進めていきます。 まずは、EC2サーバを作成するための周辺環境を構築していきましょう。 1.VPC VPCとは、Virtual Private Cloudの略です。 AWSという広大な領域
opsworksでnginxのログをltsvで出力する - Qiita
場面 nginxのログをtd-agentでtailするときにltsvにしたい 見るところ log_formatの定義箇所 https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.10/nginx/templates/default/nginx.conf.erb#L15-L17 定義したlog_formatを呼び出す箇所 https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.10/unicorn/templates/default/nginx_unicorn_web_app.erb#L9-L15 やってみる stack settingsのcustom jsonいじるだけでできる。必要なのは2点。 node[:nginx][:log_format]["<
OpsWorksの予期せぬ挙動に備える - Qiita
この記事の問題はopsworks-agentが自動でアップデートされてしまうというのが原因で引き起こされていましたが、現在（2015/07/06）は手動で利用するバージョンを指定してアップデート出来るようになったのでこの記事の問題が置き無さそうです！！ヨカッタですね！！ http://blogs.aws.amazon.com/application-management/post/TxLZ972TREEZ4A/Manage-agent-updates-on-AWS-OpsWorks-managed-instances OpsWorksを利用していて意図せず本番環境のRubyのバージョンが上がってエラーが出るという障害に遭遇してしまったので詳細を共有します。 TL;DR OpsWorksは、こちらが意図しないタイミングでサーバー内に保存されているCustom Cookbooksを最新に更新し
AWSでデプロイとスケーリングを自動化する方法まとめ - Qiita
概要 AWSではアプリケーションのデプロイや、システムのスケーリングを自動化することができます。 しかしそれらを実現しようとすると、似たようなサービスの中から用途に合ったものを選ぶ事になると思います。 今回は選択肢となり得るサービスを挙げて、それぞれの出来る事、出来ない事をベースに比較していこうと思います。 比較の軸 以下のように、評価軸を設けました。 サービスの機構として提供されているものは◯とします。 機構として提供されているが、使い難いものは△とします。(例: AWS CLIを利用した場合のみ利用可能など) 機構としては提供されていないが、別の機構などを組み合わせることで容易に実現可能なら△とします。 別の機構などを組み合わせても辛い場合や、実現不可能なら×とします。 デプロイ自動化 まずはアプリケーションのデプロイを自動化するサービスの比較を行います。 以下の4つの選択肢があります
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
さくらのクラウドでAuto Scaling ~ Docker活用編 ~ - Qiita
(デプロイ編②)世界一丁寧なAWS解説。EC2を利用して、RailsアプリをAWSにあげるまで - Qiita
