by @appwatcher 以前下記で書かせていただいた goからiOSまで一人でアプリ開発をしてたらいつの間にかマインクラフトエンジニアになった話 ですが、上から下まですべてを担当して個々の技術をすべてやった経験自体も勉強になったのですが、 どうして、そのような技術選択をしたか？という点が自分でも振り返ってみて学ぶ点がありました。 それぞれ良し悪しがあったので何かしらの参考になればと思い、それ以後の技術変遷や取捨選択を踏まえて、振り返ってみたいと思います。 なにかしらの参考になれば。 ちなみに未だに一人です。 今回の技術選択をした時の基準や自分なりの戦略 スピード重視。これは今回に限らず自分自身の戦略です。基本通常の人の３倍のスピードでやる気概でやってます。 ユーザーグロース重視。これはサービス立ち上げからやるので当然。 コスト重視。今回フリーになってコストまできちんと意識するようにな
【インフラ編】TECH LEADの技術を惜しげも無く公開します！React × PHP Laravel × BEAR.Sunday × SSR - TECH LEAD Blog
こんにちは、@TECH LEADです。 今回、「TECH LEADの技術を惜しげも無く公開します！」シリーズの最後となるインフラ編になります。 アーキテクチャー編 フロントエンド編 サーバーサイド（アプリケーション層）編 サーバーサイド（内部API層）編 インフラ編 ←いまここ 目次 目次 主な技術 インフラツール インフラ構築 インフラ構成 ネットワークに関して ミドルウェアに関して メール送信に関して インフラモニタリング まとめ エンジニアの皆さんへお願い PR TECH LEAD Job TECH LEAD Resume TECH LEAD Agent 主な技術 Amazon EC2 Amazon Aurora Amazon S3 Elasticsearch 6.4 nginx PHP-FPM インフラツール Terraform Ansible インフラ構築 TECH LEADでは
頭の中を整理するために、新たにチーム開発を始める時に決めることをリストアップしてみました。すべて書き出すと大量になるので、プロセスや開発基盤を中心に書いています。 プロジェクト計画 ゴール マイルストン スコープ リリース計画 プロセス チーム構成 リスクと対策 プロセス スプリントスケジュール（例：月曜開始の1週間スプリント） 会議体の設定（例：スプリント計画、スプリントレビュー、レトロスペクティブ） 複数チームのワークフロー（例：プロダクトオーナー、UXデザイナー、開発チーム、QAチーム） 仮説検証サイクル（例：仮説設定、リリース、分析） 進捗管理方法（例：リリースバーンダウン） 品質管理方法 障害対応のワークフロー プロセス改善の仕組み（例：レトロスペクティブ結果のバックログ化） プロダクトデザイン（略） ソフトウェアアーキテクチャ（略） インフラアーキテクチャ（略） テスト計画（略
Docker Advnet Calendar 2014の6日目の記事となります. 今日は, ｢DockerでオレオレVPSを作った話｣というタイトルで, 最近作った｢Pocker｣という名前のアプリケーションを紹介したいと思います. どうしてそのようなアプリケーションが必要になったのか, その中でのDockerの使い方や, 利用したテクニックなどについてお話できれば, と思っています. あらすじ 自分は昔から｢さくらのVPS｣を愛用していて, 趣味で作った小規模な自分用ウェブアプリのようなものを, VPSの上に複数個設置していました. さくらのVPSは非常に安価で, しかも価格が固定という事もあり, 小規模なウェブアプリを共存させるには最適だったのですが, 1つのVPSに複数のWebサービスを設置してくると, ｢ゴミが溜まってくる｣という問題が出てきます. つまり, うまく管理していないと
入門Ansibleを出版しました¶ この度「 入門 Ansible 」を、Amazonにて出版致しました。 今までAnsibleに関する日本語の本はありませんでしたが、Ansibleの入門書的な位置づけとして、まずこれを読めば分かる、ということを目指して執筆しました。 本書を執筆するにあたり、レビュー頂いた方々に感謝致します。 内容はちょっと長いですが、以下の通りです。 はじめに Ansibleの特徴 Ansibleはシンプル ChefやPuppetとの違い Ansibleは "Better Shell Script" Ansibleを使ってみよう インストール inventoryファイル モジュール (module) playbookを作ってみよう YAMLの文法 playbookを書いてみる playbookの解説 task handler よく使うモジュール 複雑なplaybookを
アプリとサーバーの通信にJSONではなくSQLiteを使うと幸せになれるかも知れない条件まとめ - アニマネ開発日誌
軽い気持ちで投稿したら、思わぬ反響を頂いたこの話。 賛否両論で色々な意見を頂きました。 問題点も含めてある程度メリット・デメリットが見えてきたので、最後にまとめてみます。 ブコメ、Twitterで色々と意見を頂いた方々ありがとうございました。 この場を借りてお礼申し上げます。 前回までのおさらい クライアントとサーバー間で何らかのデータの受け渡しをする時に、 よく使われるフォーマットとしてJSONやXMLがあります。 構造がシンプルなテキストで汎用性が高いため、あらゆるプラットフォーム間の差異を吸収するフォーマットとしてメジャーな存在です。 モバイルアプリも例外ではないのですが、JSONなどを使わずにSQLiteのDBファイルを直接渡してやりとりするというのが先日書いた記事です。 SQLiteはクロスプラットフォームな上に1ファイルで完結するので、1つのファイルで様々なプラットフォームから
これだけはやっておきたい〜マイクロサービスのデプロイメント - クラウドワークス エンジニアブログ
Scala大好きインフラエンジニアの九岡(@mumoshu)です。マイブームはConcourse CIですが、今日はマイクロサービスの話をさせていただきます。 TL;DR; 「サービスの負荷上がってきたし、マイクロサービス化しよう。マイクロサービス化って、Railsアプリ分割して、それぞれCapistranoでデプロイしておけばいいんでしょ？」*1 マイクロサービス化をするためには、アプリケーションだけでなくインフラや運用のことも考える必要があります。 この記事では、クラウドソーシングのクラウドワークスが来るマイクロサービス化に向けて認識しているデプロイメント上の問題とその対策を紹介します*2。 テストからデプロイまでがめんどくさいよ問題 →Dev/Prod Parity、Infrastructure as Code、CI、ビルドパイプライン リリースに1時間かかるよ問題 →ビルドキャッシ
DNS における Master/Slave vs Primary/Secondary の現状（2020/06） - suu-g's diary
BLM の関係でコンピュータ業界の Master / Slave という言葉遣いにもメスが入ろうとしているいま、 DNS ではどうなっているんだっけ、というのがふと気になった。 というのも mattn さんの blacklist/whitelist master/slave に関する情報集め を見たから。あとコメントもしたから。 で、調べて行ったところ、ひとことで言えば既に Primary / Secondary になってるんだけど、そもそもこの用語自体そんな使わないよな、と思ったのだけど、そのあたりを解説するのは元記事の関心ごとと全く違うってことで、改めて自分のブログの記事にしてみたというわけ。 DNS は趣味でしかないので、ツッコミ大歓迎です。 Primary/Secondary が正しい用語です 用語に困ったら RFC 8499 (Jan, 2019) が正しい参照先。こう書いてある
AWS Amplifyが変えた世界
筆者の技術スタック AWSに出会う前 筆者の技術スタックは以下のとおりです。 Webに関するフルスタックエンジニアエンジニアというのがわかりやすいのかもしれません。 フロントエンドからバックエンドまでいっしょくたに提供してた時代からのエンジニア その名残で今もフロントエンド、バックエンド、インフラ構築までおしなべて行ういわゆるフルスタックエンジニア 前職にて社内のインフラ整備だったりお客様の環境構築を任されることが多かった 現在の会社からAWSを学び始める とりあえずやってみよう！という精神を生かして 何でも手を出してた事から、アプリケーションを構築する会社で絶対数が少なくなりがちな インフラ部分を任されることが多かったと思います。 さくらのVPSなどに対して すべてのアプリケーションが整うお手製のシェルをメンテナンスしながら、 一発で環境を整えることに快感を覚えておりました。 Ansib
4年11ヶ月勤めたドワンゴを退職しました。2019年1月17日が最終出社日で、1月中は有給休暇消化期間で、2月から新しいところで働きます。 4年11ヶ月と書きましたが、半年間育児休暇をとっていたので、その期間を引くと実際働いたのは4年5ヶ月です。 4年制の大学(の文学部書道学科)を卒業して、新卒でとある会社に就職して、いろいろあってドワンゴは4社目でしたが、それ以外の会社で最長で2年程度しか勤めたことがなかったので、そう考えると5年近くも続いたのが感慨深いですね。 このblogを読んでいる人ならばある程度の人は知っているかもしれませんが、気づいたら個人的にScalaにとても詳しくなってコミッターにもなって、ドワンゴでの仕事も、ほぼずっとScala書いていました。 もちろん、デプロイツールやちょっとした管理ツール、細かい運用上のなにかで、多少Python, ansible, shell sc
CTOになったToriです。せっかくの機会なのでエンジニアとしてのキャリアを振り返ってみました - Findy Engineer Lab
前職のAmazon Web Services（以下、AWS）でコンテナスペシャリストソリューションアーキテクトやデベロッパーアドボケイトを務め、2022年4月より株式会社カミナシに転職したHara Tori(@toricls)さん。 2022年7月1日に、彼がCTOに就任したことが発表されました。 Findy Engineer Lab編集部は、就任間もないToriさんにインタビュー。著名エンジニアである彼が、どのような経験を積んでスキルを研鑽してきたのか、そしてカミナシで何を目指すのかを伺いました。彼の歩みから見えた「エンジニアがより良いキャリアを実現するための方法」とは。 「あなたは大手企業には向かないと思う」 ――改めまして、CTO就任おめでとうございます。せっかくの機会ですので、Toriさんのキャリアを総括したインタビューをさせてください。コンピューターに興味を持ったのは、いつ頃から
2013-2014年の年末年始の連休を利用して開発したIT勉強会を網羅したアプリケーション『俺の勉カレ』を全面リニュアールしました！ 見た目はちょこっとしか変わっていないように見えますが、実は裏側はほぼすべて作りなおしましたw 今回はリニュアールの目的と、リニュアールでどんな技術を使ったのかを中心に紹介していきます。 🎉 リニュアールの目的 初期構築したアプリケーションでは、Microservicesのまねことみたいなことを夢想していて単機能ごとに6個のアプリケーションで構成されていました。 しかもかなりの運用工数がかかるような謎設計で、昔の自分の頭のなかがいかにお花畑だったかを思い知らされます。 こういった失敗を踏まえて、 * できるだけ運用が楽な仕組みにする * 運用工数を最小化できるような構成にする * 自分が興味のある勉強会を見つけやすくする を基本コンセプトに、裏側をほぼすべて
こんいす～。 @ikura-hamuです。チーム「リアクティブ二子玉川～♪」でISUCON13に出ました。チームブログはこちら（まだ） 最近の若者はsshしないらしいですよ。 僕は最近のノリに乗っている若者なので、ISUCONでsshせずに作業するツール群「isu-isu-h」（いすいすえいち）を整えました。最近の若者はsshじゃなくて いすいすえいち するらしいですよ。 リポジトリ https://github.com/reactive-futakotamagawa/isu-isu-h-13 (本当のリポジトリはIPアドレスとかいろいろ上がってるのでコピーです) 名前は競技が終わってから考えました。ISUCONで自分たちの代わりにsshしてくれるのでこの名前です。 構成大きく分けて、手元の１コマンドで全サーバーでデプロイを行うansibleと、ブラウザで必要な情報を見るobserver(
アプリケーションの開発環境を Ansible でつくる - Hatena Developer Blog
こんにちは。アプリケーションエンジニアの id:aereal です。 この記事ははてなエンジニアアドベントカレンダー2014の1日目です。 今日はアプリケーションの開発環境を作成する手順を Ansible でコードとして表現し自動化する取り組みとその背景について簡単に紹介します。 前提 この記事で扱うアプリケーションは Perl と JavaScript で書かれた中規模の Web アプリケーションです。 アプリケーションを開発するチームのエンジニアとデザイナすべてが Mac OS X を使っています。手元で開発する際には VM などを動かさずに OS X でアプリケーションを起動させます。 また、開発やデプロイなどにおいて SOCKS プロキシを通してアクセスする必要のあるサーバが存在します。 開発環境の構築手順を始めとしたドキュメントは Redmine の Wiki にまとめられていま
入門Ansible
2. Agenda ๏ 自己紹介 ๏ 本セッションについて • 本セッションの扱う対象である Ansible とは何か？ • 本セッションの対象者 • 本セッションで話すこと・話さないこと ๏ Ansibleを使う前に思いそうなこと • Ansibleを使うと何が嬉しいのか？ • 他の類似ツールとは何が違うのか？ • Ansibleを動かすのに必要なシステム要件は？ • どんな企業が実際に使っているのか？ ๏ Ansibleの基本的な使い方 13年9月15日日曜日 3. Agenda ๏ 自己紹介 ๏ 本セッションについて • 本セッションの扱う対象である Ansible とは何か？ • 本セッションの対象者 • 本セッションで話すこと・話さないこと ๏ Ansibleを使う前に思いそうなこと • Ansibleを使うと何が嬉しいのか？ • 他の類似ツールとは何が違うのか？ • Ansib
はじめに Elasticsearchを仕事で使うことになったので導入前に考えるであろうことを調査・検証し、まとめてみました。 記載されている内容はほぼ公式ドキュメントから引っ張ってきています。それぞれの章にリンクを付けてありますので、記載されていること以外に気になる部分があればそちらを参照されるとよいと思います。 インストールについて ここで設定している内容はすべてansibleのスクリプトに落としてあります。 5分あればcurl,javaのインストール、Elasticsearchのインストール・初期設定、プラグインのインストールが終わるはずです。 https://github.com/uzresk/ansible-elasticsearch2 環境 CentOS6.7 Java1.8.0_45 Elasticsearch 2.1.1 HeapSizeの設定 Elasticsearchが使
「君のスキルはウチの新人と同レベルだけど、そんなんでやっていけるの？」と言われて今の会社に入社することを決めたのはもう4年半ほど前のこと。 前職はテスターでコードは全然書けなかったしデータベースとかも触ったことなかったけど好き勝手やらせてもらった結果、それなりのエンジニアに成長することができたと思う。 それも今月いっぱいで退職なのでちょうど良い機会だし自分じゃないとできなかった(やらなかった)ようなことを中心にざっくり振り返ってみる。 ※イマイチだったことは全部書いていくとキリがないので省略 Perl(CGI + 生DBI)製Webシステムの改善 Template-toolkitをwrapするPerlモジュールを作った HTMLがscriptタグも含めて1行ずつ丁寧にprintされていたのでメンテナンスが辛かった SQLも文字列連結で組み立てられていたり、無理矢理1行に詰め込まれていたりし
Dockerはシステム界隈に大きな衝撃を与えました。それはシステム管理にとってはまさに大躍進だったのですが、Dockerには、少々、致命的な誤解があるのです。 非常に限定されたアドバイス ここで取り上げるDocker議論は、ほぼミッションクリティカルなシステムにおけるマルチホストのセットアップに限定されたものです（Webサービスが主）。それを念頭においてください。でないと、私からのアドバイスは、他のケースには、おそらく意味をなさないでしょう。 Dockerの背景 この記事では、Dockerとは何か、Dockerの一般的な動作については、すでに基本的な知識がある前提で話を進めていきます。 Dockerについて、すべてを網羅するのは、この記事の目的の範疇を越えてしまうので、Dockerについて、自分は初心者だという方は、まずは以下のサイトに目を通してください。 Dockerとは何か？ Dock
この記事は、SaaSのサーバ監視サービスMackerelを起源を遡り、そこから現在の姿に至った経緯をはてな社内のエンジニアに共有するためのものです。 なお、ここに書かれていることは、Mackerel開発チームの公式見解ではありません。 概要 Mackerelは、もともとは2007年ごろに開発されたはてなの社内のサーバ管理ツールであり、動的なインフラストラクチャに対応するために、現在でいうところのInfrastructure As Codeを目指したものです。 そこから2013年にSaaSのサービスとして開発され、コードベースとアーキテクチャは全く新しくなり、監視機能を備え、サーバ「監視」サービスと呼ばれるようになりました。 しかし、はてな社内では、プログラマブルなAPIを備えたサーバ「管理」サービスとして、Mackerelを中心にしたインフラストラクチャを構築しています。 Mackerel
本番環境の監視をZABBIXからPrometheusに切り替えてから3か月程度経過しました。 今回は Prometheus 導入に関してハマったところ 現在のPrometheus活用状況 といった所を紹介したいと思います。 「Prometheusって何？」という方はこちらをご覧ください。 tech.willgate.co.jp Prometheus導入でハマったところ メール送信設定 Rプロキシ経由にする 現在のPrometheus活用状況 現在の構成 ECインスタンスの監視 設定のバージョン管理 種類豊富なexporter 柔軟なPromQL Grafanaとの組み合わせ まとめ その後の取り組み（2019/11/12 追記） Prometheus導入でハマったところ 紹介するところ以外でも色んなところでハマったのですが、代表的なところを紹介します。 メール送信設定 Alertmanag
mobilelaby.com 上記で紹介されていたiPhoneを接続した時に写真アプリの自動起動を防ぐターミナルでのコマンド defaults write com.apple.ImageCapture disableHotPlug -bool NO これ便利。実は他にもある。さらに、コマンドライン経由から設定することで、設定アプリではUI上不可能な値も設定できるので設定してまとめてみた。 フォーマット まずはdefaultsコマンドのフォーマットから 一般的なフォーマット サードパーティ製のアプリも含め、Dockの設定などがこちら。 書き込み defaults write DOMAIN KEY -TYPE VALUE 読み込み defaults read DOMAIN グローバルドメイン グローバルドメインと呼ばれる領域がある。これはジェネラルな内容、キーボードのキーリピート設定やマウスの
株式会社ドワンゴを退職しました | ゴミ人間.com
退職エントリ、一回書いてみたかったので書いた。 3 月末でドワ社を退職しました。さみしい...。好きです、ドワンゴ。 死ぬ前にもう一度ドワンゴで働きたい。 入社してみてどうだったか 想像以上に自由だった（ただしやることをしっかりやってる必要はあります）。自席を良い感じの空間にしても怒られないし、ごちうさ見ながら仕事してたりしても何も言われなかったし、20 連休とか平然と取得可能だった（普段ちゃんと仕事はしてます...）。ドワンゴが自由といわれる世の中じゃなくて、当たり前にドワンゴのような働き方ができる世の中になってほしい。 本物の裁量労働を経験したい方は、ドワンゴへ入社してみてください。厚生労働省は本物の裁量労働制がどんなものか、視察しにくるべき。 ドワンゴでやったこと 主にこんなかんじ。 ニコニコ静画（電子書籍） 入稿・配信サーバー ニコニコ静画（イラスト・マンガ） 各種アプリケーション
Shin x blog Advent Calendar 2013 の 24 日目です。 先日リリースされた vagrant-serverspec を使って、テストドリブンなサーバ構築を行ってみました。 vagrant-serverspec は、サーバ、インフラの状態をテストするツール serverspec を Vagrant のプロビジョナとして実行できるプラグインです。これを使うことで、vagrant コマンドから、serverspec のテストを実行することができます。 詳しくは、@ryuzee さんの下記エントリを参照して下さい。 vagrant-serverspecを使ってプロビジョニング結果をテストする | Ryuzee.com 仕様 今回構築するサーバの仕様は下記です。PHP 5.5.x をインストールして、ビルトインサーバを起動するというものです。（※ちなみにビルトインサーバ
こんにちは。こむろです。 今年の札幌の夏はハードモードだ（湿気と暑さ） この先生きのこるためにエアコンが投入されました。 はじめに クラウドネイティブなアプリケーションを設計・構築・運用している皆さんは、普段どのようにアプリケーションやインフラの更新作業を行っているでしょうか。 順次インスタンスやコンテナを切り替えていくRolling Update？それとも環境を複製してDNS Routingの切り替えによるBlue-Green Deploymentでしょうか。他にも様々な方法があるかと思いますが、今回もまたBlue-Green Deploymentにおける実際の現場で発生した事象について報告したいと思います。 あまりネット上にもこういった情報が出てこないようなのですが、皆さんこういった問題は軽々とクリアされているのでしょうか。自分がポンコツなだけなのかととても不安にかられるばかりです。
ISUCON予選突破の鍵は過去問を解くことなので無料で試せるようにした(Vagrant+Ansible) - このブログはURLが変更になりました
タイトルでいいきった。 ISUCON5参加者へのアドバイス まもなくISUCON5が開催されますね。 毎年参加して予選突破を果たしている私からのアドバイスは、過去問を解いてチューニング力を高めることが重要です。これホント大事。 過去問やってる？ ですが、ISUCONの過去問はAWS用AMIとソースコード一式が用意して提供されているものの結構難しいんですよね。 AWSの利用は課金がつらい（特に学生） AWSの利用はクレジットカードが必要でつらい*1 ソースコードから構築する方法がわからない（AMIの中身を見ないとわからないこと多数） 無料で過去問やろう そこで無料かつ簡単に手元で構築できるよう、VagrantfileとAnsible用Playbookを用意しました。 https://github.com/matsuu/vagrant-isucon/ https://github.com/ma
２ヶ月くらい使ってみたけど、悪くはないんだけど、なんか最近持ち上げられすぎてる気がするので、気になったところを書き出してみる。 あくまで個人的な感想なので、マサカリ投げるのは歓迎。 概要 Noticeを含むエラーが全て例外になる 最近のフレームワークは大体やってそうだけど、エラーを出すと全て例外を出すので、不要にcatchしなければ問答無用で落ちる。これにより、NOTICE出しっぱなしで何となく動いているコードを殲滅できる。標準にしてほしい。Fatalも例外として扱ってくれるが、Fatalを取れるのはプログラム終了後なので、特に意味はない。出力が同一フォーマットになるくらい。 ちなみに自前で実装するにはErrorExceptionのページに書いてあるので、この通り実装しよう。簡単である。 ファイルの配置が自由 composer autoload使っていればどれでもそうなんだけど、Model
let’s encrypt で複数ホスト名対応な証明書を作る タイトル通りですが、割と簡単に複数のホスト名に対応した証明書が取得できるので、やってみました。 今回は ansible playbook のおまけ付きです。 let’s encrypt の困った問題 let’s encrypt ではワイルドカード証明書が無いので、複数のホスト名を1台のサーバでホスティングできないため、ちょっと困っていました。 ググって調べてみたら、let’s encrypt は SAN 対応の証明書だったら発行できる、と言うことだったので実際にやってみました。 その前に、SAN って何よ？ ワイルドカード証明書だと良く聞くと思うのですが、 SAN って何よ？と思う人も多いと思います。 SAN とは Subject Alternative Name の略称で、サブジェクトの別名です。 ん？サブジェクトってなに？
AnsibleはChefやPuppetと同様に冪等性（べきとうせい）に配慮した構成管理ツールです。YAMLで記述したプレイブックのファイルが1つあれば動き、SSHさえ繋がれば対象サーバーにクライアントは不要、といったシンプルさが支持され、近年ユーザーを増やしています。 そのシンプルさは仮想マシンを利用した開発環境の構築にもうってつけに思えます。と言うことで今回はAnsibleをVagrantのプロビジョナーに使って開発環境を構築しました。 Ansibleの公式サイト Ansibleのインストール Ansibleはコントロールマシンに入っていればよく、セットアップ対象のサーバにはAnsibleのクライアントなどは不要です。SSHで接続さえできればOKです。今回のケースでは開発マシンのMacをコントロールマシンとし、Vagrantによる仮想マシンをセットアップ対象とします。 Ansible自体
1時間1円から使えるSSD VPS、DigitalOceanことはじめ - yutaponのブログ
DigitalOceanといえばSSD VPSなのに1時間当たり約1円弱で使える格安VPSとして有名です。 有名な紹介記事はこちら。 徳丸浩の雑記帳: 試験環境用VPSとして1時間1円から使えるDigitalOceanが安くて便利 VagrantとSSDなVPS(Digital Ocean)で1時間1円の使い捨て高速サーバ環境を構築する - Glide Note DigitalOceanのことはrebuildfm#2で知って興味持ちました。 Rebuild: 2: Rails, Redis, VPS (Kenn Ejima) それまでVPSといえばさくらVPSがメジャーだと思ってましたが、 調べてみるとDigitalOceanがなんとも良さ気です。 今回はDigitalOceanの登録から簡単な使い方を説明します。 こちらのリンクから登録していただくと、私に少しバックがあるようです。 Di
はじめに 以前こんな記事を書きました。（ほぼリンク集ですが・・） tekunabe.hatenablog.jp 今回はこれのプレゼン資料版のような記事です。ここ半年くらいの資料を対象にしています。 具体的なツールの使い方などのスキルとは別に、考え方についても備えていきたいと思っています。 運用自動化、不都合な真実 いろいろと考えるきっかけになった資料です。 "「やれるところから始める自動化」は弊害を生む" "使う人が自分で作るしか無い、という結論" 生き残る運用管理者 ～運用自動化を成功させる人、失敗させる人～ "成果だけ出したい人にはお手軽なため「焼畑農業的な運用自動化」をする人に注意が必要。" その運用自動化では行き詰まる 〜「つながらない」「つたわらない」「つみあがらない」を防ぐために〜 (2018/07/17リンク追記) リクルート流SRE インフラ運用がサービスを変える世界 新卒
2021/10/22追記：最新版は下記記事になります！こちらもご一読くださいませ。 tech-blog.abeja.asia どうも、Tech Blog編集長(自称)の緒方(@conta_)です。 よくエンジニアの方にご質問いただく ABEJAってよく聞くけど、実際どんなことやってるのかよくわからない という点をクリアにするために、事業内容と技術視点でのABEJAの取り組みを紹介したいと思います。 ABEJAに興味のある方や、未来の一緒に働くメンバーに読んでいただけると嬉しいです！ 割とAIコンサルの会社と思われているらしいので、ちゃんとプロダクト作ってますよ！ということを伝えていきたい ABEJAの事業紹介 ABEJAは2012年から約7年間、機械学習・ネットワークやIoTデバイスを活用したプロダクトの研究・開発・運用を行っています。 様々な産業・業種へ機械学習の適用・運用を培ってきたナ
The Observability Pipeline that delivers monitoring as code on any cloud Consolidate monitoring tools & fill gaps in observability. Eliminate data silos & automate diagnosis & self-healing — from bare metal to Kubernetes. $ sensuctl create -r -f monitoring/ check "node-exporter" created check "tls-cert" created asset "sensu-plugins/sensu-plugins-ssl:1.0.0" created filter "oncall" created handler "
サーバーレスアーキテクチャーも大胆に導入！ 自律・自走できる組織作りを進めるカオナビのインフラチーム - はてなニュース
タレントマネジメントシステムを提供する株式会社カオナビでは、サービスをSaaS型にシフトするにあたってAWS（Amazon Web Services）を全面的に採用し、サーバレスの基盤開発でもAWSのマネージドサービスを積極的に活用しています。 そのベースにある「運用しない運用」という言葉の意図や、計測・監視の取り組み、アプリケーション開発の経験も活用できる「自走するインフラ組織」について、インフラグループの大久保智之さんと新井健さんに聞きました。 ※この記事は株式会社カオナビによるSponsoredContentです。 AWSへの移行から技術的な挑戦を進める サーバレスを推進して温かみある手順から脱出 開発の経験も生かしたアプリケーション監視と指標 自動化の原則は自走と自律 カオナビではエンジニアを積極募集しています！ AWSへの移行から技術的な挑戦を進める ── プロフィール（後掲）を
2年くらい前までは、brewdleが行方不明になったり、そのせいでBrewfileはオワコン扱いされたりといろいろありましたが、 Homebrew CaskがHomebrewに取り込まれたことでセットアップ界はだいぶ落ち着いたと思われます（自分調べ）。 というわけでHomebrew関連のセットアップツールについて現在の状況をまとめました。 なお、AnsibleとかBoxenとかについては触れません。ご了承ください。 Homebrew Cask Homebrew Caskは簡単に言うとその辺に転がっているパッケージをインストールできるツールです。 もともとは後述するbrewdleで有名になったと記憶しているんですが、便利すぎたので本家に吸収されちゃっています。 $ brew cask install alfred $ brew cask install android-studio $ br
全て 1.このサイトについて 2.作品DB開発/運用 3.ホームページ制作技術 4.Perl 5.C言語 / C++ 6.検索エンジン&SEO 7.サッカー 8.自分のこと 9.Linux 10.旅行 11.思ったこと 12.パソコン 13.Berkeley DB 14.その他技術系 15.企画 16.スマートフォン 17.鑑賞 18.皆声.jpニュース 19.インターネット業界 20.運用マニュアル(自分用) 21.技術系以外実用書 22.料理 23.ALEXA 24.アニメ 25.会計 26.漫画 27.設計書 28.色々サイト作成 29.サーバー 30.自分専用 31.生活 32.OP/ED/PV 33.ゲーム 34.DB整備 35.新規開始作品紹介 36.英語圏の話題 37.大道芸 38.映画 39.PHP 40.ダイエット 41.Mac 42.JavaScript 43.MySQ
You Can Shape Trend Reports: Participate in DZone Research Surveys + Enter the Prize Drawings! Hello, DZone Community! We have several surveys in progress as part of our research for upcoming Trend Reports. We would love for you to join us by sharing your experiences and insights (anonymously if you choose) — readers just like you drive the content that we cover in our Trend Reports. check out the
もう5年以上続けている取り組みのひとつにデスクトップ環境をdisposableに保つというのがある。いつでも何があっても即座に環境を捨てて作り直せるようにするということ。EC2やVPSのインスタンスに対してAnsibleでプロビジョニングできる状態にしておけば即座に新しいホストを立てて古いホストを捨てられる、そんな状態を目指すということ。具体的には以下のようなことを心がけている。 書類のマスターデータを端末上に置かない デスクトップ環境をdisposableに保つ第一歩は、とにかく手元になんらかのデータのマスターを置かないことにつきる。端末上にマスターデータを置いていると当然新しい環境を用意する際にデータ移行が必要になる。移行をしないためにはこれらを手元に置かないようにする。書類はGoogle DriveやNASに入れる、ソースコードは全てGitHubに上げておく、などなど。現代では機密情
補足：2021年6月 結構昔に書いた記事ですが、今でもたまにアクセスがある（ありがとうございます）ようなので使命感に駆られて追記。 本編の冒頭にもあるように、これは2018年の記事です。なので色々と書いてますが、2021年の人間の立場からTypeScriptの導入について申すのであれば一言です。 使いましょう。 もはや「TypeScriptを使う理由」とか言ってる時代はとっくの昔に終わっています（Elmとかそういう、他の型付きAltを使いたいなら別ですが）。 もちろんstrict mode一択ですからね。 当時は採用云々とか書いてましたが、逆にいまTypeScript書けるかどうかってのはフロントエンドエンジニア採用の足切りラインとしてちょうどいいくらい（書けるってのが程度かにもよりますけど）だとおもいます。 好き嫌いはともかく、TypeScriptを使えないエンジニアを雇ってもフロントエ
LinuxベースのネットワークスイッチOS「OpenSwitch」が、Linux Foundationのプロジェクトに
Linux Foundationは、いわゆるホワイトボックス用のネットワークスイッチOSをLinuxベースで開発する「OpenSwitch」が、Linux Foundationのプロジェクトになったと発表しました。 OpwnSwitchは、米ヒューレット・パッカードやメラノックス、ブロードコム、インテル、LinkedInなどが昨年10月に立ち上げたオープンソースプロジェクト。 スイッチなどのネットワーク機器は、ネットワークベンダが独自のハードウェアと専用のOSを開発し、組み合わせて提供されるものでした。それをサーバと同じようにハードウェアとOSの業界標準を作ることで、自由にベンダーやユーザーが組み合わせて利用できるようにする動きが強まってきています。 そのハードウェアがいわゆるホワイトボックススイッチであり、例えばFacebookが設立したOpen Compute Projectなどでホワ
@t_wada さんの「Mac の開発環境構築を自動化する (2015 年初旬編)」をAnsible ベストプラクティスに則り書き換えてみた - production.log
概要 t-wada.hatenablog.jp Ansibleでmacの環境構築する際、id:t-wada さんの上記の記事を参考したのですが、 Ansible Best Practicesに沿っていなかったので、書き直してみました。 Ansibleを動かすまで こちらは、t_wadaさんの記事のままです。 sudo xcodebuild -license xcode-select --install ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)" brew doctor brew update brew install python brew install ansible どこを直したのか twada/macbook-provisioning hoshin
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ひとりぼっちのサービス開発における技術選択の遷移と戦略 - Qiita
チーム開発を始める時に決めること - GeekFactory
DockerでオレオレVPSを作った話 - Masteries
入門Ansibleを出版しました — そこはかとなく書くよん。 ドキュメント
ドワンゴを退職しました - xuwei-k's blog
IT勉強会を探しやすくするWebアプリケーション『俺の勉カレ』をリニュアールしました
【 #ISUCON 】 最近の若者は ssh しないらしいですよ
Elasticsearch導入前に気を付けておきたいこと！ - Qiita
エンジニアにジョブチェンジしてやってきたこと - daisuzu's notes
Dockerにまつわる誤解とベストプラクティスについて | POSTD
サーバ「管理」ツールとしてのMackerelの起源 - ゆううきブログ
Prometheusで本番環境の監視をして3か月経ちました - WILLGATE TECH BLOG
OSXのコマンドラインからすると捗った設定リスト - will and way
vagrant-serverspec で TDD ライクにサーバ構築を行う
Blue-Green Deploymentにおける注意点 | DevelopersIO
Laravel5を業務で一通り使ってみた感想 - nazolabo
let's encrypt で複数ホスト名対応な証明書を作る - 日記
AnsibleとVagrantで開発環境を構築する | さくらのナレッジ
自動化を考える前に読んでおきたいプレゼン資料たち - てくなべ (tekunabe)
ABEJAの技術スタックを公開します (2019年11月版) - ABEJA Tech Blog
Sensu | Observability Pipeline
Homebrewを取り囲むセットアップシェル界隈の情勢（2016年5月版） - Qiita
Ngram(N-gram)とは何か & 形態素解析との比較
dzone.com
デスクトップ環境をdisposableに保つ - あんパン
TypeScriptを導入する前に考慮したほうが良いこと 4項目 - タオルケット体操