タグ

2017年7月7日のブックマーク (10件)

  • Chef/初心者向けChef入門講座/はじめてのcookbook - インターネットウィキ

    cookbook |- attributes(ディレクトリ) … ここで定義した値をレシピファイル内から読み込むことができる |- definitions(ディレクトリ) … いくつかの処理(リソース)をまとめた別の処理を定義するファイルを置くディレクトリ |- files(ディレクトリ) … 各レシピから使用する設定ファイルやアーカイブファイルなど、各種ファイルを置くディレクトリ | |- default(ディレクトリ) … defaultレシピ用のファイルを置くディレクトリ | |- libraries(ディレクトリ) … 各レシピで共有するライブラリを置くディレクトリ |- providers(ディレクトリ) … |- recipes(ディレクトリ) … 実際の処理内容であるレシピを配置するディレクトリ | |- default.rb(ファイル) … cookbook名のみを指定して

    jinjin252525
    jinjin252525 2017/07/07
    chef
  • [EC2] 不要なAMIを一括で削除したい | DevelopersIO

    こむろ@今だけ東京です。 はじめに 担当プロジェクトでは、Golden AMI方式でデプロイプロセスを構成しているのですが、検証環境では比較的頻繁にデプロイを実行します。そしてふと気づきました。はて?AMIが増えると問題ないのだろうか? AMI の登録解除を確認すると、EBSのSnapshotが残っているため、こちらが課金対象です。検証環境を調べてみるとその数なんと300個超え。これはよろしくありません。塵も積もれば山となる、不要なものは整理していきましょう。そこで、手始めにすでに利用しないであろうAMIを削除していきます。 AMIの削除は一発で終わらない 先程のドキュメントを確認してみると、どうやらAMIの削除は少々面倒そう。今回はEBS BackedのAMIなので、以下の手順が必要です。 AMIの登録解除 登録解除したAMIに紐付いたSnapshotの削除 さすがに200個超えをマネジ

    [EC2] 不要なAMIを一括で削除したい | DevelopersIO
    jinjin252525
    jinjin252525 2017/07/07
    ami snapshot
  • Nginx - ファイルディスクリプタ設定(Too many open files 対策)!

    Linux では、1プロセスが同時オープン可能なファイルディスクリプタの上限に達すると “Too many open files” などというエラーを発生します。 OS 上でのファイルディスクリプタ設定についての記事は結構存在するので、対策はそれほど難しくありません。 しかし、Web サーバ Nginx が絡むと若干ワナにかかる可能性があります。 以下、その事象、対策についての記録です。 不勉強なので、それほど突っ込んだ内容ではありません。当方が行なった対策についての記録です。 0. 前提条件 CentOS 6.5 上での作業を想定。 Web サーバは Nginx 1.4.7 を想定。 Web アプリ・サイトは Ruby on Rails で構築されていることを想定。(当方の場合) 1. 発生事象・原因 突如、自前で運用中の Web サーバにアクセスると、ブラウザ上に以下のようなメッセージ

    Nginx - ファイルディスクリプタ設定(Too many open files 対策)!
  • Terraform + CodeDeploy[Ansible]って使い物になるのか | iret.media

    よく大宇宙状態(謎)になっている先輩が、terraform+codedeploy+ansibleを試していたので 当に使えるかどうか実践してみました。 AWS CodeDeployを使ってAnsible or itamae + Serverspec http://qiita.com/gamisan9999/items/c4e26bf99189bed82748 全体像 先輩の記事だけ見ていると何しているかよくわかんなかったので、わかりやすくしてみました。 ちなみに、TerraformとCodeDeploy+Ansibleは完全に別物です。 連携はまったくありませんのであしからず。 TerraformAWS環境を構築、EC2とかCodeDeployとかもろもろ作成。 AnsibleレシピをCodedeployでS3にアップ。 CodeDeployからS3のファイルをデプロイ。 後は、対象の

    Terraform + CodeDeploy[Ansible]って使い物になるのか | iret.media
  • AutoScaling(オートスケーリング)時のデプロイのベストプラクティス(CodeDeploy) - keiwt’s diary

    AutoScaling(オートスケーリング)時にはLaunchConfigのAMIを元に新しいインスタンスが作成されます。 しかし、GitHub等のリビジョンが進んでいると新しいインスタンスのみ古いリビジョンのソースになってしまいます。 そのため、主に以下の2つの方法があります。 デプロイの度にAMIを作成して、AutoScalingGroup(オートスケーリンググループ)とELBを差し替える サーバー内の変更時もデプロイ時も常に同じことをすればいいので、判断が不要になることが利点です。 しかし、デプロイの度にAMIを作成して、AutoScalingGroupとELBを作成して、 CodeDeployのApplicationStopイベントが初回のデプロイ時には動かないため、 AutoScalingGroup(オートスケーリンググループ)に対して1回デプロイして、 Route53のCNAM

    AutoScaling(オートスケーリング)時のデプロイのベストプラクティス(CodeDeploy) - keiwt’s diary
  • SSSSLIDE

    SSSSLIDE
  • SSSSLIDE

    SSSSLIDE
  • はじめての AWS CodeDeploy (プラス Auto Scaling) | DevelopersIO

    こんにちは、菅野です。 突然ですが、Auto Scalingって便利ですよね。 昔 Auto Scaling を使っていた時の話ですが、PHPのプログラムを変更する度に AMI を作り、Launch Configurations を作り直して・・・といった作業をしていました(所要時間20分くらい)。 昔の話なのでもういいのですが、AWS CodeDeployを使えばそんな苦労は不要らしいという事を知り今回初めて使ってみることにしました。 今回の目標 AutoScaling により作成されたEC2インスタンスへブラウザでアクセスした時に表示されるwebページを AWS CodeDeploy を使って更新する webページの管理に GitHub を使う では早速始めましょう! EC2 の準備 インスタンスを作成します。 作成時にタグを一つ追加しておいてください。(apl-name:test-a

    はじめての AWS CodeDeploy (プラス Auto Scaling) | DevelopersIO
  • AutoScaling導入によって得たメリットと気をつけたいポイント - Qiita

    AWSにはAutoScalingという便利な機能があります。AutoScalingは負荷の状況や指定した時間に自動的にインスタンスを用意してくれる機能です。 ソーシャルゲームの様なアクセスがピンポイントで大量にくるような場面で大変活躍してくれます。 そんなAutoScalingを導入して得たメリットと導入の際に気をつけたいポイントについてお話しようと思います。 インスタンス構築時間が30分から5分に!! スケジュール機能により、必要な時間に必要な台数をコントロール!! サーバ費のコスト削減!! 1. インスタンス構築時間が30分から5分に!! アプリサーバがいますぐ欲しいんです!こんな依頼が時にはありますよね? 今まではアプリサーバを構築するのにインフラの手とアプリエンジニアの手が必要でした。 まず、インフラがEC2を建ち上げ、chefもしくはansibleでプロビジョニングします。その後

    AutoScaling導入によって得たメリットと気をつけたいポイント - Qiita
  • AWS ECSのサービスをslack botでデプロイする - クラウドワークス エンジニアブログ

    みなさんさようなら.インフラ部の@h3_potetoです. CrowdWorksは大きなRailsアプリケーションですが,最近ではこの大きさで管理していくのもう無理な気がしてきて,マイクロサービスっぽくしていこうという動きがあります(が,まだ全然マイクロサービスではないです). それでも一部を切り出すことには成功していて,多少なりともマイクロサービスの運用っぽいことも必要になってきました. で,今回は僕の趣味のデプロイの話です. サービスはDockerに載せたいよ CrowdWorks体は,Docker化まで程遠い感じがしているんですが,切り出したマイクロサービスなら,最初からDocker前提で作ることが出来ます. これなら楽にDocker番運用まで行けそうな気がしていました. 他のサービスを色々AWS上に構築していることから,Dockerでアプリケーションを動かすのもAWSでなんと

    AWS ECSのサービスをslack botでデプロイする - クラウドワークス エンジニアブログ