わかる!metadata.managedFields / Kubernetes Meetup Tokyo 48Preferred Networks
![Drone.io のご紹介](https://cdn-ak-scissors.b.st-hatena.com/image/square/881f105bd2e48744f762e9497b5455ba3b746d84/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Fdroneio-casual-open-150313063436-conversion-gate01-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
わかる!metadata.managedFields / Kubernetes Meetup Tokyo 48Preferred Networks
はじめまして!今年1月からジョインしましたtjinjinです。feedforceではアニメインフラを担当しています。ちなみに今季オススメアニメはSHIROBAKOです。 今回サーバCIにDockerを導入しましたので、実際の設定や工夫した点など投稿したいと思います。 feedforceのサーバCI 弊社ではこれまでCircleCIまたはJenkinsとAWSを組み合わせてサーバのCIを行って参りました。 参考: JenkinsでサーバのCIを始めました しかし、CircleCIを利用するプロジェクトが増えるにつれ、CircleCIに実行待ちが発生するようになりました。CircleCIの実行ログを確認したところ、AWSのセットアップに時間がかかっていることがわかったので、環境のセットアップ時間を短縮できるもののはないかと探していました。そんな折、Dockerがいいのではという話を耳にしました
追記(2017年7月) こちらのスキル要件ですが、2017年版を新たに書きましたので是非そちらをご覧ください。 「データサイエンティストというかデータ分析職に就くためのスキル要件」という話題が某所であったんですが、僕にとって馴染みのあるTokyoR界隈で実際に企業のデータ分析職で活躍している人たちのスキルを眺めてみるに、 みどりぼん程度の統計学の知識 はじパタ程度の機械学習の知識 RかPythonでコードが組める SQLが書ける というのが全員の最大公約数=下限ラインかなぁと。そんなわけで、ちょろっと色々与太話を書いてみます。なお僕の周りの半径5mに限った真実かもしれませんので、皆さん自身がどこかのデータサイエンティスト()募集に応募して蹴られたとしても何の保証もいたしかねますので悪しからず。 統計学の知識は「みどりぼん以上」 データ解析のための統計モデリング入門――一般化線形モデル・階層
AWS は、従量課金なので、他者からの不正利用(本来無いことですが)や想定外の利用で、翌月の請求が来て、ビックリということがあります。 私自身も関わっているプロジェクトで、ある月に平時の数倍の請求が来て、原因調査を行ったという経験がありました。 転ばぬ先の杖ということで、先にやっておくべきことについてまとめておきます。 1. AWSアカウントの不正利用を防ぐ まず、考えられるのが、アカウントを乗っ取られての不正利用です。もちろん、不正利用は、請求だけでなく、システムやリソースを守るという点でも防ぐべきことです。 そこで、AWS アカウントは、2要素認証(2段階認証 / 2 Factor authentication / 2FA)を設定しておきます。 手順は、下記のエントリがまとまっています。 AWSアカウント作ったらこれだけはやっとけ!IAMユーザーとAuthyを使ったMFAで2段階認証
はじめに AWSチームのすずきです。 AWSのシステム側に起因するEC2障害が発生した場合、 インスタンスのSTOP、STARTによる再起動操作が必要となる事があります。 この再起動を自動化する「Auto Recovery」機能が東京リージョンでも利用可能となりましたので紹介させていただきます。 Auto Recovery設定 Auto Recovery、AWSコンソールのCloudWatch画面で設定します。 詳細な設定手順は、Auto Recoveryが先行提供されていた米国リージョンと同じです。下記記事をご覧ください。 【新機能】EC2 Cloudwatchの新機能「Auto Recovery」を使ってみた まとめ AWSのEC2環境が稼働している仮想ホストやネットワークなどに物理的な障害が生じ、 EC2インスタンス障害に至る可能性、頻繁に発生するものではありませんが、0ではありませ
あけましておめでとうございます。本日から仕事始めの戻る皆様も多いと思います。 冬休みを利用して Ansible と Git と Jenkins を組み合わせた継続的デリバリのための環境を自宅環境に作ってみましたので、こちらに残しておきたいと思います。書いてみたら長くなってしまいましたので、数回に分けています。 初回は、環境概要の紹介から、それぞれのシステムでのセットアップ、SSHでの接続確認までです。 環境概要 以下の表は今回のシステム概要です。自宅のLAN内にあるESXi上で完結する構成にしています。 用途 台数 ホスト名 IP Address 補足 テスト対象サーバ 5 stage01 stage02 stage03 stage04 stage05 192.168.0.101 192.168.0.102 192.168.0.103 192.168.0.104 192.168.0.105
継続的デリバリ環境を作ってみたシリーズの続きです。前回は環境概要の紹介とそれぞれのシステムでのセットアップまでご紹介しました。今回はサンプルで用意したAnsibleのplaybookを使い、実際にJenkinsから動作させるところまで書いていきたいと思います。 プロジェクトの作成(ローカルリポジトリの作成) GitHubにサンプルを置いてますので、それを使ってローカルリポジトリを作成することにします。 今回は “ansible-jenkins-sample” というプロジェクト名で作成しました。 ローカルリポジトリ置き場となるフォルダを作成します。 サンプルのリポジトリのローカルリポジトリにクローンします。 SourceTreeで『新規 / クローンを作成する』を左クリックし、リポジトリをクローンする設定を行います。さらに、リモートリポジトリの削除をしてしまいます。自動的にクローン元のGi
前回、playbook のサンプルをローカルリポジトリとリモートリポジトリに登録し、Jenkins 経由で実行するところまで試すことができました。今回は、特定ブランチ用のジョブを作成し、ビルド・トリガを設定して実行するまで試したいと思います。 特定ブランチ用のジョブを作成し、ビルド・トリガを設定して実行する 今までの Jenkins ジョブでは*/masterブランチに対する手動実行でしたが、特定のブランチ用のジョブを新たに作成し、コミットするたびにビルドが走るようにしたいと思います。 特定ブランチ用のジョブを作成する CIサーバの Jenkins Web UI にアクセスし、『新規ジョブ作成』で今まで利用していたジョブをコピーします。今回は “maint” ブランチを作成する前提で、以下のような設定をしています。『ジョブ名』 を “ansible-jenkins-sample.maint
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く