活动消息

无人运维会议东京第二次活动 – connpass

NoOps = 没有不舒服的运维运营
NoOps Japan致力于”消除系统运维保守中的不愉快之事！”，我们希望共享关于实现NoOps所需的技术、设计方法、开发运营维护周期、工具、思维，以及案例等等。
在NoOps Meetup Tokyo #2上，我们会邀请业界的权威人士继续发表演讲，以不同的观点谈谈NoOps。

NoOps Meetup Tokyo #1 会议笔记- Qiita
这里是第一次会议的笔记。

資料連結收藏夾

• NoOps Meetup Tokyo #2 Opening

 

• MicroserviceでのNoOps戦略 – NoOps Meetup Tokyo #2 #NoOpsJP

 

• The NoOps strategy and tactics

 

なかなか楽にならないSSL/TLS証明書の話 – Speaker Deck

岡大勝是Opening/NoOps Japan的发起人。

• NoOps Meetup #1 振り返り

Publickeyで第一回が記事として取り上げられている

NoOpsを実現できる時が来た。「NoOps」とは運用の“嬉しくない”ことをなくすこと。NoOps Meetup Tokyo ＃1 － Publickey
「NoOps？ よろしい、ならば戦争だ」 NoOpsコミュニティに異議申し立てた「Opsの味方」 決裂か？ 和解か？ NoOps Meetup Tokyo ＃1 － Publickey

「やめることを決める」ことが大事

やめようと言い出すハードルは低くないが、前向きなやめかたをする

NoOpsに向かう準備は整っている

コンテナ、サーバレス、DevOps、SRE …

みんな違ってみんな良い

背景/手段はたくさんある、いろんな観点を重ねながら学んでいきたい

Meetupでは知の共有、OpenHackでものづくりを進めるコミュニティ作りを進める
行動指針

オープン＆フラット
共感駆動のSRCA(Sympaty-Respect-Contribute-Appriciate)

スポンサー募集中
Microsoft Tech Summit 2018 / Japan Container Days 2018 登壇します

Microsoft Tech Summit 2018 | インフラエンジニア、アーキテクト、IT IT 戦略にかかわる皆様の為の技術カンファレンス – Microsoft Events & Seminars
Japan Container Days v18.12

在微服务中的NoOps策略 / 铃木雄介 @yusuke_arclamp增长专家伙伴

• NoOpsとは / 歴史経緯

ITサービスのライフサイクルを早くする（企画、実装、運用、利用）
2001年 アジャイル

アジャイルソフトウェア開発宣言

企画→開発 のスピードアップ

2009年 DevOps

アジャイルをインフラや運用の仕事にも適用する
開発-運用
10+ Deploys Per Day: Dev and Ops Cooperation at Flickr

2011年 NoOps

運用はいらない？運用担当者はいらない？という議論へ
NoOps炎上事件
Augment DevOps With NoOps

その後の議論

2012年 Netflix / Ops, DevOps and PaaS (NoOps) at Netflix

カナリアリアリリース、アラート収集、Cassandra用運用ツール
DevOps/SREチームがこれらのツールを作成
運用するための組織は存在せず，開発者は運用者と話す必要はない
開発者を運用から開放し、セルフサービスツールを提供する

Why 2013 is the year of ‘NoOps’ for programmers [Infographic]

90年代 データセンター集約
2006 API(AWS)
2011 SysOps(Puppet/Chef)
2012 AppLifecycle(CloudFoundry/OpenShift)
2013 NoOps(Heroku)

NoOps総論

運用作業の自動化とツール化

ツール化するエンジニアがいる

開発者はツールを使って運用作業を行う

作る と 動かす の距離がなくなる

ツール化により役割分担が変わった

機能要件だけでなく非機能要件まで
プログラマの役割が変わってきた

2014年 Microservices

先端的なウェブサービス企業が似たようなアーキテクチャスタイルを取っている
なぜMicroservices？

目的：サービス全体を止めずに一部を変更する
解決：変更発生単位にサービスとして分割し、APIで連携させることで変更時にサービス全体を止めない

MicroservicesとNoOps

Microservices にNoOpsは織り込み済み

運用作業の自動化、ツール化は重要な土台
「アプリを作る」から「サービスを動かす」へ

全員が NoOpsを目指すべき

NoOps とは まとめ

「サービス全体を止めに一部を変更する」ために主に「運用作業の自動化とツール化」を推進すること
開発者にとっては「作る」から「作って動かす」へ
「うちはAWSじゃない」「既存のツールが使えない」は思考停止

サービスを管理せよ

アプリとインフラを一体で管理する

「インフラを用意して、アプリをインストールする」ではなく「サービスとして管理する」
PaaS

そもそも対障害性、無停止リリース機能を持ったPaaSを利用する
すごく便利だが制約に従う必要がある、実現できることと制約が比例する

コンテナ

ネットワーク/ミドルウェアを含めた構成のバージョン管理
ほぼ制約なし
コンテナ対応PaaSを利用すると便利

発想の転換：動かす時にインフラ調達

「インフラを用意してアプリを置く」ではなく「アプリを動かす時にインフラを調達する」
バッチサーバという概念はいらない、バッチジョブを起動するタイミングでインフラ調達する

ありがちな課題の解決

固定IP、固定ドメイン前提になってる→動的対応する
エージェントが必要→エージェント不要にしていく
設定ファイルで環境切り替え→設定をリポジトリ化
DB関連が手動→コード化

その先へ

コンテナオーケストレーション、サービスメッシュ
イベントソージング

实现IT基础设施的NoOps战略和方法论/中岛伦明 @Irix_jp Red Hat

• NoOps = 戦う階層を変えること

従来インフラではストレージ、サーバ、DB等と戦ってきた

安全に確実に動かす、コストを最適化する、に加えて「変化への対応」という3軸目が重要に

1度作ったインフラが変化するのは当たり前

パッチ適用、バージョンアップ、設定変更、リソース増減 …

戦略的なアプローチ

先に考えること：状態

どういう状態にするか、どういう状態になればComfortableなのか

後で考えること：方法

どう作るか、どうやって実現するか

戦略的な考え方とは

戦術のみを知って戦略を知らざるものは、ついに国家をあやまつ

今、エンジニアに最も必要なものは「戦略」である！孫氏に学ぶ本質のつかみ方
イゼルローン要塞攻略に学ぶエンジニアの戦略思考

クラウドファースト、コンテナファースト、自動化ファースト
NoOpsへの戦略的アプローチ

モデルとなる状態を定義：他の成功者を参考にすると近道
その状態に行き着くために障害となるギャップを抽出
解消できるギャップ、出来ないギャップ（法律とか業界とかの縛りなど）を整理して、ToBeを描く
ギャップ測定

バリューストリームマッピングで抽出・可視化

理想的な環境ではどうなるか
現状とのギャップ、障害となるものは何か

今すぐできること、将来的にやること、やらなくて良いことを整理

自動化の戦術

置換：単純に手順を置き換える、
機能化：サービスとして切り出して別の人に実行してもらう
連結：小さな機能を連結して大きな機能を作る

アンチパターン：全部自動化しなといけない、一気通貫で自動化しなければならない、今の環境のまま自動化しないといけない

戦略的：運用が発生しないアーキテクチャで始める
戦略的：自動化しやすい環境を整える
戦術的：簡単なやりやすいところから自動化してしまう
戦術的：難しいもの、複雑なものをそのまま自動化する

证书的问题并不容易解决/しばやん @shibayan

• SSL/TLS証明書の管理がしんどい

12ヶ月に一回位の作業
認証局からのメールで期限を思い出したり忘れたり

DV証明書発行の流れ

認証局にCSRを投げる
ドメインの所有を確認する

whoisに登録されているメールアドレスにリンク送信、指定されたTOKEN入のファイルをサーバに置く、DNSで指定されたレコードを追加するなど

証明書が発行される

中間証明書と一緒にサーバに配置したり、PFXにしたり

自動化されない理由

自動化が難しい作業ばかり：CSR作成、ドメイン所有の確認、証明書と秘密鍵の配置
12ヶ月ごとなので、手動でもなんとかなっちゃう雰囲気（自動化のコストが割に合わない）
そもそも認証局が自動化前提の作りじゃない

更新忘れると

SSL/TSL通信がうまくいかない

ブラウザが警告出す、ブラウザ意外の通信も同様

最近は常時SSLやHSTSの流れにより致命的

Windows Azure、11時間にわたる全世界的なストレージ障害。原因はSSL証明書の失効 － Publickey

致命的な問題に発展するのに、なかなか楽にならない

楽にしようとする動き

クラウドベンダが認証局をもつ：AWS Certificate Manager
外部認証局とパートナーシップを結んでる：Azure Key Vault/App Service Certificate
Let’s Encrypt を利用している/ACMEプロトコルの導入：GCP の Managed SSL、さくら など数多くの例

AWS Certificate Manager

ELB/ALB/CloudFront/APIGatewayで使える

パブリック向けの場合、ワイルドカード証明書も発行可能、マルチテナントのアプリケーションにも使いやすい

自動的に証明書の更新を行ってくれる

条件：ドメインが利用中かつSSL/TLSで外部からアクセス可能な場合
IP制限している場合は、メールが飛んできてURLを踏む必要がある（今までと同じく手動の作業が出てくる）

無料

Azure Key Valt

DigiCert と GlobalSignと連携、予めアカウントを作る必要がある
事前に指定したポリシーに従って更新してくれる
自己証明書の発行もできる
おそらく有料

App Service Certificate

GoDaddyと連携している、AzurePotalから購入可能
自動更新
有料：1ドメイン$69.999、ワイルドカード$299.999

Let’s Encrypt

ACMEプロトコルに基づいた自動での証明書発行

公式のcertbotを使って管理可能
v2からはワイルドカードも可能

HTTPかDNSを利用してドメイン所有の確認
無料で使える

ACMEプロトコルについて

認証局が証明書発行に必要な機能を定義している
REST-API
対象のドメイン全てに対してHTTPSかDNSで確認される

特殊なファイル、もしくはTXTレコード書き換え

certbot が使えるケース

nginxやApacheを直接公開している場合
Let’s Encrypt公式クライアントなので安心

各クラウドのManagedDNSに対応（Azure除く）

Linuxのみサポート

所感

AWS Certificate Managerが突出して便利
Let’s Encrypt周りを面倒見てくれるManaged SSL良さ
Azureは無料で使えるSSL証明書がない

まとめ

SSL/TSL証明書管理は自動化できる（DVのみ）
AWSならAWS-CM、GCPならManagedSSLを使う
Azureはお金払うか、コミュニティ作成のIssuerを使う
Let’s Encryptに感謝を