opsだけどgitを使ってみた～その１
こんにちは。小宮です。 opsだけどgitを使ってみた～その１ということで、githubもgitlabもgitも初心者なので忘れないようにメモ。 今回はたどたどしくpushするところくらいまでにします。branch切ってみるとこは初回から書くとおなかいっぱいになりそうなので。 たぶんその２までです。その２はbranchとtagとconfrictのことを書いています。 背景とメリットデメリット ・背景 昨今の継続的インテグレーションだとかでchefでサーバ構築の需要があってその流れ弾に当たった機会を得たため、 そのリポジトリをバージョン管理する必要が生じましてgitをつかうことに。最初は会社のエンタープライズ版のgithubに保存してもらっていたんですが、 VPN経由でのやり取りの需要からgitlabの導入を行うことになりました。 ・gitのメリット ヒストリ追わなくていい。見える化。ファイル内の差分が見やすいので確認がブラウザで容易に可能になる ・gitのデメリット 同僚がつかいはじめてくれない（必要にせまられないと忙しくてスルー傾向） まあなんか気持ちはわかります。私もきっかけは半ば強制的な感じでした。 githubとgitlabの違い gitコマンド的にはあんま変わんない気もしますが、制度がオープン(エンタープライズはクローズ可)かクローズでいけるか、 gilabの場合は容量制限もディスク容量とかの環境次第でユーザ権限を細かく設定できたりなどするのがいい感じです。 もっというとVPN越しにしかつながらないようにしたいとかの自由がききます。共有Webサービスつかうか自前構築のつかうかの差です。 gilab導入の手間は最近はchefで気軽に入るレシピもあり軽減されてきたようです。 githubの場合、二段階認証をなんとかする 詳細な説明は省きますが、まずgithubに登録して会社のgithubの二段階認証をなんとかします →会社で用意していただいたマニュアルのとおりに実施。 要はgmailの2段階認証みたいなことで携帯にSMS通知が届いて認証する仕組みのセットアップです。 接続するホストでsshの鍵の作成と、作成した公開鍵の登録をgithub側のユーザプロファイルで行います。 pushするホストでgitを初期設定する まずgitコマンド打つ人のユーザ情報を登録です。 git config --global user.email "komiyay@xxxxx"` git config --global user.name "Yxxx Komiya" 設定ファイルにメモリ制限やスレッド数を指定しないとOutOfMemoryエラーが出ます。 $ vi ~/.gitconfig [user] email = komiyay@xxxxx name = Yxxx Komiya [core] packedGitWindowSize = 128m packedGitLimit = 128m [pack] windowMemory = 128m threads = 2 deltaCacheSize = 128m packSizeLimit = 128m ※m1....DevOps時代のアジャイルでスケーラブルな開発環境をVagrant, GitHub, Travis, Chef, OpsWorksで構築する
どうも。久しぶりです。 デベロッパーの平形です。 このブログに訪れたすべてのエンジニアの方々。 そして、エンジニア以外の方々。 とても感謝致します。 初めに言っておきますが、この記事ではコード、コマンドラインの一切は登場しません。 はじめに 私が今回お送りする内容は本当にスケーラブルな環境の構築、運用を手助けする事ができます。 連載記事で複数回に渡ってお届けしますが、この連載を読み終えそして実践していただければ、あなたは既にスケーラブルな環境で作業を行っている事でしょう。 この連載記事では、順番に必要なツールのインストール、使い方をハンズオン形式でお送りします。 実際に手を動かして実感していただく事がとても意味がある事だと思っています。 この回では、コード、コマンドラインは一切登場しません。次回以降にどんどん出てきます。 その前に**「伝えたい事があるんだ。君の事が好きだから」by小田和正**と叫ばせてください。 この記事は以下の方には不向きです。 俺は一生一人で生きていくんだ！と1日1回はトイレで意気込んでいる人。 後先の事なんか考えたくない。俺は今を生きているんだ！と週に３回は言っている人。 これらに該当する方。お疲れ様でした。出口はこちらです。 この記事は以下に該当する方に是非読んでいただきたいです。 開発者、インフラ担当者の方。 これから新しいプロジェクトを立ち上げるんだけど、構成どうしようか悩んでる方。 サーバーの台数が多くなったらどうしよう。と悩んでいる方。 開発要員が急に増えたらどうしよう。と悩んでる方。 DevOpsとかスケーラブルな環境とかに興味があって、でも今ひとつ踏み出せない方。 上記を実践してみようとしたけど、挫折してしまった方。 開発環境で動いているコードがなぜか公開環境で動かなくて家に帰れない方。 本番反映が怖くて会社に行きたくない方。 サーバーが落ちる事が不安で夜も眠れない方。 将来の事を考えると不安で不安で仕方なく、「とにかくもう、学校や家には帰りたくない〜。」by尾崎豊と口ずさんでしまう方。 それでは、夢の扉を開きましょう。 レガシーな開発と運用 開発環境、公開環境の構築は、構築手順書を元に手動でインストールしている。 公開環境のサーバー増設は１台ずつ手動でキッティングしている。 パッチの適用、バージョンアップは手動で１台ずつ手順書を元に実行している。 バージョン管理はしないで各自、修正ファイルをFTPでファイルをアップロードしている。 これらをヒューマンエラーなく、ストレスなく運用できるのはスーパーマンです。 そして、開発、運用メンバー全員が自分と同じスーパーマンでなければいけません。 凡人の僕には無理です。 現代の開発と運用 現代のもの凄い勢いで変化するサービス要求に耐えるには、様々なものを効率化しなければいけません。 素早くリリースしてユーザの反応を見ては仕様を変更してすぐに反映しまたリリースする。といった事も必要です。 近頃、開発運用の自動化は様々なメディアの記事で取り上げられ、賑わっています。 しかし、実際にどこまで自動化ができているのでしょうか？ バージョン管理 環境構築 セキュリティパッチの適用 バージョンアップ オートスケール 自動テスト 自動デプロイ 開発環境の配布 なかなか全部はできないですよね？ でもやったほうが絶対に幸せになれます。...GitHubでpush時にAWS OpsWorksで自動デプロイする方法
開発の平形です。 今日は、GitHubでpush時にAWS OpsWorksで自動デプロイする方法をお教えします。 OpsWorksはAWSで提供されているデプロイのサービスです。 ＊OpsWorksについては、こちらのサイトが詳しいです。 この話は、OpsWorksにスタックとレイヤとインスタンスが存在する前提です。 OpsWorks自体、最近触ったばかりですが、 デプロイがすごく簡単にできるという事はよくわかりました。 でも、欲張りな僕は、もっと自動化できないのかな？と思ったのです。 普段、ソースはGitHubでバージョン管理しているので、 GitHubにpushしたら同時にデプロイできないのかな？と。 そしたら、ビックリするほど簡単に実現できました。 GitHub側で設定が可能です。 アプリケーションのリポジトリのページの「Settings」 「Service Hooks」 AWS OpsWorks 以下の項目は全て必須なので、全部入力します。 ここで、OpsWorks側の情報が必要になります。 まずは、Stack Idですが、一見これがわかるところが、AWS Managed Consoleの画面上にはありません。 手っ取り早くこれを確認する方法はStackの画面のURLをみる事です。 次にApp Idですが、同じくOpsWorksの画面で、「Apps」=>「アプリケーション名」をクリック OpsWorks IDがApp Idです。 Branch Nameはリポジトリのデプロイしたいブランチ名を指定。 AWSのアクセスキーとシークレットキーを入力し、Update settingsをポチっとします。 あとは、該当ブランチにpushするだけ！ これで自動的にOpsWorksのデプロイが走ります。 僕はこれに感動しました！ ただ、欲張りな僕はまたまた思ったのですね。 OpsWorksではスタックを本番環境とステージング環境と分けて運用してるとします。 そうすると、 releaseブランチはステージング masterブランチは本番 にそれぞれ自動デプロイできたらいいなー、と。 しかし、一つのリポジトリにつき、一つのスタックの設定しかできないんですよね。 という事で「できない」という事がわかり、取り乱しました。 まあ実際の運用で、masterのpushしただけでいきなりデプロイするのもトラブルの元になりそうだし、 そういうもんなんだ。って自分に言い聞かせて落ち着きを取り戻しました。 それでも便利には変わりないですけど。 あなたのデプロイライフがもっと充実しますように。 以上、平形がお届けしました。...