20200831 Infra Study Meetup #5 memo

情報

セッション

基調講演「企業に必要とされるインフラ技術のこれから？」

  • 資料

  • インフラエンジニアでコードが書ける意味

    • APPエンジニアであろうと本質的には変わらない。テストもしっかりと
    • Ansible -> Serverspec 時代（ライフサイクルが長くなっている）
    • コンテナ時代は、短くなってる
    • ライフサイクルに合わせたコードを書けるか。３日くらいしか使わないコードを書くこともある
  • インフラエンジニアのキャリア形成について
    • キャリアモデルを見つけること
    • この人すごい、とか思うとよい。人となりとか
  • IaC 何を使う？
    • 自分がコントリビュートできるかどうかが判断する基準
    • 未来はわからない。コントロールできるかどうか
    • 今後の研究テーマとなっている（＃１の人）
  • 学び続けること
    • 成功体験を作れている点
    • 社会人になってから
  • オンプレメリット
    • 事業規模
    • 物理サーバを直接使える
    • NW敷くので技術的知識が増える
    • マネージドは、一気にコンテナを１００とか起動できる
  • リンク

LT1「組織の壁と戦うための Hierarchical Namespace」

LT2「システム監視、何からはじめる？」

  • 資料
  • 監視難しい
  • サービスが正常てあることを監視する
    • サービスの正常は、チームごとに異なる

20200826 Kubernetes Meetup Tokyo #33

Qrunchからの移行（ログ）

セミナ情報

セッション

Kubernetesでの性能解析 ～ なんとなく遅いからの脱却 ～

AWS CDK との比較で見る cdk8s / cdk8s+ の現在地

  • 資料
  • cdk8s はYAMLを生成するツール
    • 構築をするのではない

20200805 CNBF Meetup #2 bookmark

セミナー情報

資料ブックマーク

memo

  • SOMPO のコンテナ利用の現実説明
  • DENSO のコネクティッドカーでk8s 活用関連（IoT/エッジ）

20200729-30 Cloud Operator Days Tokyo 2020

Qrunchからの移行（ログ）

セミナー情報

参考リンク

セッション

A-1-3 プロダクト運用のCloudOps化に伴うジレンマ

  • 資料
  • 自動化、効率化言うは易いが、実際は容易でない。総論賛成、各論反対の状況
  • クラウド運用におけるジレンマ
    • 既存踏襲
    • Dev優先、Ops優先
  • イノベーションのジレンマ
    • 持続的（Ansible）
    • 破壊的（Kuberenetes）
  • すべての創造は「たった一人の熱狂」から始まる

B-1-4 次世代MSPに求められるクラウド運用とTips

  • 資料
  • 次世代MSP
    • 技術要件１２項目（★参考になる資料）
  • 監視は以下を使用
  • 信頼とエンジニアリング
    • SREとCRE（お客様の不安をエンジニアリングで取り除くこと）
    • ドキュメント作成能力を重視している（★）
  • クラウド運用のTips
  • マルチクラウド運用

C-1-5 Infrastructure as Code の静的テスト(チェシャ猫さん)

B-2-2 大量のKubernetesクラスタを管理するための課題とVolterra Edge Serviceにおけるアプローチ

  • SaaS でEdge 統合を行うサービス提供会社
  • 3000拠点あると、中央集権的にスケールさせることはできない
    • 大量のメトリック、ログが集まってくる
    • センターサイトの肥大化
  • k8s をベースに拡張している

資料（視聴していないセッション）

20200729 Infra Study Meetup #4 資料一覧

Qrunchからの移行（ログ）

「インフラの面白い技術とこれから」

資料

20200728 Kubernetes Meetup Tokyo #32 memo

Qrunchからの移行（ログ）

Kubernetes Meetup Tokyo #32

1人運用を支えるAmazon EKSノウハウ

  • https://speakerdeck.com/hi1280/amazon-eks-know-how
  • ひとり運用でマネージドサービスをフル活用
  • 管理・監視には課題あり(P49-53)
    • AWS のリソース管理とEKS での管理が分断している（一貫性がない）
    • eksctl では新規作成しかできない
    • Prometheus+Grafana 監視がつらくなってきた
      • SaaS を使うべきかも

Introduction to Flagger: Progressive Delivery Operator for Kubernetes

  • https://speakerdeck.com/mathetake/introduction-to-flagger
  • Flagger というk8s 向け先進的なCDツール
  • 理想的なCDは、NoOps
    • 現実は人手の作業を排除できない
  • All-or-nothing ではなく、徐々にデプロイする方式
    • Test in production の考え方に近い
  • 実装例としてFlagger
    • 内容をちゃんと理解していきたい

20200727 cndjp15 memo

Qrunchからの移行（ログ）

アプリエンジニアが本当に必要だったCloud Nativeとは…! - cndjp15

「12 Factor App on Kubernetes を12ヶ月実践して見えてきたもの」

  • 資料
  • １年前の資料
  • インフラの構成管理はTerraform
  • Cloud Run (GKE)
  • FluxCD利用
    • エラー通知がない
  • 廃棄容易性
    • 24H VMを使用(Preemptible VM)

「アプリエンジニアを救え！ AWS CDKで実現するインフラCI・CD」

  • speakerdeck.com

  • Appエンジニア
    • 非機能に興味なし（インフラ部分）
    • インフラはやりたいことの本筋ではない
    • k8sはオーバーテクノロジ（使いたくない。。）
    • コンソールをポチポチもしたくない
    • なのでCDK
  • CI/CD の不安
    • 意図しない変更があること
    • 機械的なチェックがポイント

「みんなでつくる Resilience」

  • 回復性
    • 障害が局所化されていること
    • アプリケーションエンジニアとしての視点で、どのようにして Resilience を高めていけるか