dockerについて社内勉強会で話しました - 圧倒亭グランパのブログ
こんにちは！@at_grandpa です。 社内勉強会でdockerについて話す機会がありました。 以下に、勉強会で使用したスライドを載せます。 「dockerって聞いたことあるけどなんなんだ？」という人向けに作りました。 （自分もその立ち位置だったので） はじめてのdocker from at_grandpa 内容としては以下になります。 現在のサーバー運用が抱える問題 ( p.9 ) dockerを支える技術 ( p.56 ) AUFS LXC 実際にdockerを使う流れ ( p.85 ) pingとvimをインストールしてみる dockerのその他の機能 ( p.113 ) AUFSやLXCについては、以下のサイトが個人的にわかりやすかったです。 Dockerが利用しているAUFSとLXC スライド内で使用したURLはこちらです。 Docker: Linuxコンテナを使ってアプリ
私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログ
私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見であることを共有しておきたい。そういう意見に至った経緯をこのブログで書き留めて置きたい。 尚、これは所属会社の見解ではないことは明確にしておきます。 サム・グッケンハイマーの一言 私は DevOpsのエバンジェリストで、それ以前からアジャイル開発をかれこれ１５年ぐらい実施し、導入の支援をしている。私はかつては、日本の環境の制約の中で如何にアジャイル開発のメリットを最大に引き出すか？ということを考えていた。 ウォーターフォールに対する立場も、真っ向から否定するものでもなく、現状もあるし、それに慣れている人もいるし、実際ウォーターフォールでも失敗しない人も居る。だから、人にウォータフォールのメリット・デメリットを聞かれた時も「変化しないものに関してはウォータフォールはいいのかもしれない」と回答して
「本番環境などという場所はない」マイクロソフトがSaaSの失敗と成功から学んだ、アジャイルからDevOpsへの進化（前編）。Regional SCRUM GATHERING Tokyo 2016
「本番環境などという場所はない」マイクロソフトがSaaSの失敗と成功から学んだ、アジャイルからDevOpsへの進化（前編）。Regional SCRUM GATHERING Tokyo 2016 アジャイル開発手法の1つであるスクラムをテーマにしたイベント「Regional SCRUM GATHERING Tokyo 2016」が1月19日と20日の2日間、都内で開催されました。 そこでマイクロソフトが行ったセッション「マイクロソフトが実践したScrum導入7年間の旅。そしてDevOpsへの進化」は、アジャイル開発からクラウドサービスの提供へと進んだマイクロソフトが、サービス開発の過程で学んださまざまな知見を共有するものとなりました。 そこには、アジャイル開発の延長線上にあるDevOpsを成功させる組織と技術、そしてマインドのあり方が紹介されていました。セッションの内容をダイジェストで紹介
General tips — Ansible Community Documentation
Ansible getting started Getting started with Ansible Getting started with Execution Environments Installation, Upgrade & Configuration Installation Guide Ansible Porting Guides Using Ansible Building Ansible inventories Using Ansible command line tools Using Ansible playbooks Protecting sensitive data with Ansible vault Using Ansible modules and plugins Using Ansible collections Using Ansible on W
Ansible Dark Side - ほわいとぼーど
Ansibleは非常にシンプルかつ強力なツールですが、 様々な設定方法・書き方が許容されるがゆえにやり過ぎると収集がつかなくなります。 そんな若干やりすぎかもしれない設定の一部を晒してみます。 タイトルは若干大げさですが、お勧めするような設定ではないという自虐的な意味を込めてます。 production/staging environment variables Ansibleである程度の規模のプロビジョニングをするようになると 公式DocumentにもあるBest Practices に倣うと思いますが、 この時課題の1つとなるのがproductionとstagingで異なる環境変数をどう管理するかです。 検索してみると何種類かのやり方がHitするのですが、うちでやっている方法も書いてみます。 このやり方はAnsible始めた頃に同僚から教えてもらった方法です。 inventory/ p
Ansible オレオレベストプラクティス - Qiita
多種多様な構成のサーバーを Ansible で管理する場合、単一のベストプラクティスツリーに押し込むのは管理が大変すぎて現実的ではないなとおもい、どうしたものかなと悩んでいました。で、最近やっとこれかなという構成ができたので共有してみます。 何が問題か？ ロールには共用できるものとできないものがある、それがいっしょこたに混ざるのが嫌 無理に共用できるようにと変数を多用するととても管理が大変。変数も覚えられないし、テストが大変 読み込むファイルのパスが大元のymlからの相対パスであり、include ではディレクトリ階層での整理が難しい -l で対象サーバーを絞り込んでも全てのタスクが表示され、skipped, skipped, skipped と関係ない task 表示がターミナルが埋まって見づらい そして、たどり着いたオレオレベストプラクティス まとめて管理したいサーバーグループ毎にベス
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
