JAWS-UG 大阪 in AWS Cloud Roadshow 2015 ナイトイベントのLTで発表した資料です。Read less

serverspecはよく使っているのですが、ある状態をチェックしたいとき、その自動化に役立ちます。 例としてcrondやnginxのステータス確認などがそれにあたるかと思います。 これまでは ssh '対象ホスト' /etc/init.d/crond statusのようにやっていました。 これもサーバーが1台であったり、確認することが1つであればそこまでめんどくさくはないのですが、複数台で、複数のことがらをチェックするのは結構大変です。 なので自動化したい!っていうことなのですが、単純な使い方ならこちらの記事を参考に 一番参考になるのはなんだかんだで公式ドキュメント!DevOpsのためにチェックすべきドキュメント3選! - nigoblog serverspec - Home serverspecは基本的に ~/.ssh/configの内容を参考に動きます。 その際、ELB配下で固定IP

はじめに 当エントリはDevelopers.IOで弊社AWSチームによる2015年アドベントカレンダー 『AWS サービス別 再入門アドベントカレンダー 2015』の3日目のエントリです。 昨日2日目のエントリは大瀧の『Amazon VPC』でした。 このアドベントカレンダーの企画は、普段AWSサービスについて 最新のネタ・深い/細かいテーマを主に書き連ねてきたメンバーの手によって、 今一度初心に返って、基本的な部分を見つめ直してみよう、解説してみようという コンセプトが含まれています。 本日3日目のテーマは『Amazon CloudFront』です。 目次 Amazon CloudFrontとは CloudFrontの仕組み CloudFrontの基本的な使い方 ユースケース 高度な機能 あわせて読みたい公式情報 さいごに Amazon CloudFrontとは Amazon Cloud

こんにちは、検索・編成部ディレクターの原田です。検索・編成部では検索サービスをはじめとして、主にクックパッドでレシピを探す方に向けたサービス開発をしています。 さあ、しっかり企画を立てよう！の落とし穴 突然ですが、例えば 思いつきで施策をスタートしてしまって、後でチームのメンバーがバラバラになってしまった… 関連する部署を調整できなかった… またその逆で、誰かの思いつきの施策によって翻弄されて大変だった… という経験はないでしょうか。 個人の制約を超えて目的を達成できることがチームで仕事をすることの可能性ですが、チームワークの威力は各自が自発的に行動できるようになって発揮されるので、判断を支える明確な目標や指針を含む「企画」が必要になります。 一方で、さあちゃんとした企画を立てるぞ！ と意気込んでみても、ちゃんとしたどころか発想すら浮かばない…ということはないでしょうか。毎日の暮らしの中で

2018年4月25日をもちまして、 『CodeIQ』のプログラミング腕試しサービス、年収確約スカウトサービスは、 ITエンジニアのための年収確約スカウトサービス『moffers by CodeIQ』https://moffers.jp/ へ一本化いたしました。 これまで多くのITエンジニアの方に『CodeIQ』をご利用いただきまして、 改めて心より深く御礼申し上げます。 また、エンジニアのためのWebマガジン「CodeIQ MAGAZINE」は、 リクナビNEXTジャーナル( https://next.rikunabi.com/journal/ )に一部の記事の移行を予定しております。 今後は『moffers by CodeIQ』にて、 ITエンジニアの皆様のより良い転職をサポートするために、より一層努めてまいりますので、 引き続きご愛顧のほど何卒よろしくお願い申し上げます。 また、Cod

Effective Scala Marius Eriksen, Twitter Inc. marius@twitter.com (@marius) [translated by Yuta Okamoto (@okapies) and Satoshi Kobayashi (@scova0731)] Table of Contents 序章 書式: ホワイトスペース, 命名, インポート, 中カッコ, パターンマッチ, コメント 型とジェネリクス: 戻り型アノテーション, 変位, 型エイリアス, 暗黙 コレクション: 階層, 使う, スタイル, 性能, Java コレクション 並行性: Future, コレクション 制御構造: 再帰, Return, forループと内包, require と assert 関数型プログラミング: 代数的データ型としてのケースクラス, Option, パターンマ

Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

こんにちは、神崎です。今年の6月頃にアドサーバーのアプリケーションサーバ群をAWS ElasticBeanstalk w/ Dockerに置き換えをおこないました。 これにより、アプリケーションレイヤーのauto-scaling環境の構築、deployのフローの自動化、rubyなどのMiddlewareの入れ替えが比較的容易にできる環境になりました。 既存の環境は、以前ブログで紹介したとおり、EC2上にruby2.0でunicorn+sinatraで構築していました。 - iQONの広告配信システム - VASILY DEVELOPERS BLOG 構成 Containerの内部構成は下記のようになっており、中央にある、ad-serverがアプリケーションの実態のContainerになります。それ以外は、nginx,mackerel,fluentdのContainerがあり、それぞれが特定

2015-12-03 CircleCIのキャッシュ(cache_directories)の挙動を解説するよ CircleCI CI この記事は CircleCI Advent Calendar 2015 - Qiita の3日目の記事です。 2日目はtakusさんによる「AWS CodeDeploy と CircleCI で Docker コンテナを自動デプロイ」でした。 CircleCI Advent Calendar 2015 の 2 日目を書きました。 / “AWS CodeDeploy と CircleCI で Docker コンテナを自動デプロイ · takus's blog” https://t.co/3WI7JzoYuq— Takumi Sakamoto (@takus) 2015, 12月 1 3日目にして早くも2つ目です。後6枠ほど空いているようなので我こそはという方は是

こんにちは 現在成長期を迎え、体重は 84kg になりました。佐々木です。 今日はセカイエアドベントカレンダー3日目です。 セカイエのデプロイ事情について紹介したいと思います。 qiita.com 今までのデプロイ 今のセカイエでのデプロイは、デプロイサーバにログインしてそこからシェルを実行してデプロイを行っていました。 問題点 今から上げる問題は、セカイエで毎週行っているエンジニア勉強会の最後の問題定義時間（雑談タイム）で挙げられていた問題点です。 その時の状況でシェル書き換え問題 デプロイにはいくつか種類があって、画像の同期が必要だったりとその時の状況によってシェルを書き換えて実行したりしています。 これではいつか事故が起きてしまう可能性があります。 デプロイ担当者問題 自分もサイトに修正を加えた時に直面したのですが、リリースフローがしっかりしていなくて混乱します。 その時の状況でリリ

（この記事はGoogle Cloud Platform Advent Calendar 2015の12月3日分の記事です） Cloud Vision APIと私 Googleに入ってからまもなく5年、Google Cloud Platformのデベロッパーアドボケイト（エバンジェリストみたいな役割）の仕事に就いてから1年が経ちました。仕事の半分はアジア地域向けの開発者コミュニティ支援で、残り半分はGCPの新製品ローンチの支援をグローバル向けに行っています。 特にここ半年は、TensorFlowをはじめ、GCPの機械学習系プロダクトのローンチ支援にフォーカスしています。TensorFlowはその序章で、公開前からAlphaカスタマー向けのスライドを作ったり説明やデモしたりしていました。 そうしたGCPの新しい機械学習系サービスのひとつが、Cloud Vision APIです。これはGoogl

厳しい環境で働くエンジニアがミスしたとき、叱るのは適切な対処ではないようです。「ITエンジニアは他業種よりも高ストレス、ITスキル研究フォーラムが実態調査」と「［「うっかり」ミスは無くせる 3］叱るより真因を追究、対策べからず集」を読んでの感想です。 前者は、高いストレスを感じる割合が他の業種よりもITエンジニアが高いことを指摘したもの。後者は、どうしても起こってしまう「うっかり」ミスを減らすためには、失敗した際にしかったり罰したりするのではなく、ミスがなかった場合にほめることが有効だと指摘しています。 高いストレスの原因に長時間の労働があります。ITエンジニアは他業種よりも高ストレス、ITスキル研究フォーラムが実態調査によれば、「月当たりの労働時間との関係を見たところ、200時間を超えると高ストレス者の割合が増加しており、200時間超と回答したエンジニアの26.4％が高ストレス者だった」

Mackerelを使い始めました CTO 小芝です。この記事はanimateLAB Advent Calendar 2015 2日目の記事です。 先日、"エンジニアをワクワクさせる「直感的サーバ監視サービス」 "Mackerelを数十台のホストに一斉導入しました。 既存サービスで外部に任せていたシステム運用をインハウス化し、運用クオリティを自分たちで高めていくための取り組みの一つです。 Mackerelとは 株式会社はてなが開発・運営しているサーバ監視サービスです。 mackerel.io このような特徴がWebサイトに書かれています。 *1 経緯 アニメイトラボでは今年の夏よりエンジニアを積極採用し、当初1名だったのですが現在では総勢10人でチームを組んで新サービスの開発に邁進しています。 それと並行して、既存サービスでは外部委託されていたシステム運用をインハウス化し、ビジネス面、開発面

丹内です。 掲題の通り、モバイルのバックエンドとしても期待されているAWS Lambdaを継続的に使う際に欠かせない、リリース周りについて考えてみます。 概要の説明 先日の勉強会での発表でLambdaをProduction環境にデプロイした例をお話しました。 しかしながら実務では「デプロイしたらそれっきり」というものは少なく、ビジネスやスケールの変化に伴いコードにも変更が発生します。 日々発生する変更を安全にデプロイし、問題があったらすぐロールバックできるということが、継続的なソフトウェア開発には必要です。 Lambda Functionにはバージョニングとエイリアスという機能が、これを使うことで、Blue-Green Deploymentのようにデプロイやロールバックが可能になります。 以下の図をご覧ください。 この図は、バージョニングとエイリアスを使った場合のデプロイ例を示しています。

こんなタイトルですが、私もSSHログインしてます。 というか、shell大好きです。 で、何が言いたいかというと、SSHしなくてもいいように設計しましょう。ということ。 運用中にSSHしなければいけない理由 まず、運用中にSSHをしなければいけない理由は以下あたりかと思います。 設定変更、確認 障害調査、対応 障害調査の場合は、以下などを行います。 サーバへSSH リソース状況を確認する ログを確認する etc...(システム特有の何か) 上記の作業をする上で最も恐れるべきは「オペミス」です。 そして、調査精度は個人のスキルに依存します。 特にオペミスの場合は、再発防止策とかすごく難しいんですよね。 「経験不足」や「本番と開発環境を間違えていた」とか、「手順を間違えた」とか、、、 どう再発防止しましょうか。。。いっその事ログインしない運用とか。。。 「ログインしなければ問題起きないよね」を

はじめに 開発環境の構築や開発支援ツールの導入は、チーム開発には欠かせない工程になりますが、業務アプリケーション開発やテストなどと異なり、プロダクトの機能性や品質を直接的に高めるものではないため、なるべくインフラ構築・運用の作業を省力化したいものです。 また、開発支援ツールの多くは、開発のピーク時は開発メンバーが増員され高負荷となるものの、システムリリース後は保守などでの利用が中心になります。Dockerはコンテナ仮想化技術を使ったアプリケーション実行環境構築／運用プラットフォームです。インフラ環境も含めたアプリケーションの実行環境をすべてまとめて「コンテナ」でパッケージングできます。そこで、Dockerを導入して、開発環境のポータビリティを高めておけば、開発者の利用状況に応じた環境で効率よくインフラを運用できます。 そこで本連載では、アプリケーション開発の現場でよく利用されている次の開発