モスクワでの Slurm DevOps の登録が開始されました

TL; DR

スラーム開発運用 30月1日からXNUMX月XNUMX日までモスクワで開催される。

ここでも実際に DevOps ツールを分析します。
詳細とプログラムはカット中です。
Ivan Kruglov 氏とともに別の Slurm SRE を準備しているため、SRE はプログラムから削除されました。 発表は後ほど。
最初の Slurm 以来のスポンサーである Selectel に感謝します。

モスクワでの Slurm DevOps の登録が開始されました

哲学、懐疑、そして予期せぬ成功について

私は XNUMX 月末にモスクワで開催された DevOpsConf に参加しました。
聞いたことの要約:
— DevOps は、あらゆる規模のほとんどのプロジェクトで必要とされます。
— DevOps は文化であり、他の文化と同様に、社内から生まれてくるものでなければなりません。 DevOps エンジニアを雇って、彼がプロセスを改善してくれると夢見ることはできません。
— DevOps 変革に必要なものリストの最後に来るのはテクノロジー、つまり私たちが教えるまさに DevOps ツールです。

DevOps の哲学と文化は体系的に教えることができないため、コースに含めなかったのは正しかったと気づきました。 必要な人は本で読んでください。 あるいは、そのカリスマ性と権威で誰もを納得させる超クールなコーチを見つけるかもしれない。

私個人としては、ツールを通じて文化をゲリラ的に導入する「下からの運動」を常に支持してきました。 『フェニックス・プロジェクト』で説明されているようなもの。 Git を使用したチームワークが正しく設定されていれば、それを徐々に規制で補うことができ、その後、価値が生まれます。

それにもかかわらず、ツールについてのみ話していた DevOps Slurm を準備していたとき、私は参加者の反応を恐れていました。 残念ですが、私にはそれらを実装することはできません。」 非常に懐疑的な意見があったため、私たちはすぐにプログラムの繰り返しを中止しました。

しかし、参加者の大多数は、得られた知識は実際に応用可能であり、近い将来、自国でも何かを導入すると回答しました。 同時に、私たちが説明したすべてのものが、Git、Ansible、CI/CD、SRE などの役立つもののリストに含まれていました。

冒頭で彼らは Slurm Kubernetes について、k3s を 8 日で説明するのは不可能だとも言っていたことを覚えておく価値があります。

SRE トピックを主導した Ivan Kruglov とは、別のプログラムについて合意しました。 詳細については現在検討中ですので、近日中に発表させていただきます。

Slurm DevOps では何が起こるのでしょうか?

プログラム

トピック #1: Git を使用したチームワーク

  • 基本コマンド git init、commit、add、diff、log、status、pull、push
  • Git フロー、ブランチとタグ、マージ戦略
  • 複数のリモート担当者と連携する
  • GitHub フロー
  • フォーク、リモート、プルリクエスト
  • 競合、リリース、Gitflow およびチームに関連するその他のフローについてもう一度

トピック #2: 開発の観点からアプリケーションを操作する

  • Python でマイクロサービスを作成する
  • 環境変数
  • 統合テストと単体テスト
  • 開発での docker-compose の使用

トピック #3: CI/CD: 自動化の概要

  • 自動化の概要
  • ツール (bash、make、gradle)
  • git-hook を使用してプロセスを自動化する
  • 工場の組立ラインとそのITへの応用
  • 「一般的な」パイプラインの構築例
  • CI/CD 用の最新ソフトウェア: Drone CI、BitBucket Pipelines、Travis など。

トピック #4: CI/CD: Gitlab の使用

  • Gitlab CI
  • Gitlab Runner、その種類とアプリケーション
  • Gitlab CI、構成機能、ベストプラクティス
  • Gitlab CI ステージ
  • Gitlab CI 変数
  • 構築、テスト、展開
  • 実行の制御と制限: のみ、次の場合
  • アーティファクトの操作
  • .gitlab-ci.yml 内のテンプレート、パイプラインのさまざまな部分でアクションを再利用
  • 含める - セクション
  • gitlab-ci.yml の一元管理 (XNUMX つのファイルと他のリポジトリへの自動プッシュ)

トピック #5: コードとしてのインフラストラクチャ

  • IaC: コードとしてのインフラストラクチャへのアプローチ
  • インフラプロバイダーとしてのクラウドプロバイダー
  • システム初期化ツール、イメージ構築(パッカー)
  • Terraform を例として使用した IaC
  • 構成ストレージ、コラボレーション、アプリケーションの自動化
  • Ansible プレイブック作成の実践
  • べき等性、宣言性
  • Ansible を例として使用した IaC

トピック #6: インフラストラクチャのテスト

  • Molecule および Gitlab CI のテストと継続的統合
  • Vagrant の使用

トピック #7: Prometheus を使用したインフラストラクチャ監視

  • なぜモニタリングが必要なのでしょうか?
  • モニタリングの種類
  • 監視システムでの通知
  • 健全な監視システムを構築する方法
  • 誰にとっても判読可能な通知
  • 健康診断:気を付けるべきこと
  • 監視データに基づく自動化

トピック #8: ELK を使用したアプリケーションのログ記録

  • ロギングのベストプラクティス
  • ELKスタック

トピック #9: ChatOps によるインフラストラクチャの自動化

  • DevOps と ChatOps
  • ChatOps: 強み
  • Slack と代替手段
  • ChatOps 用のボット
  • Hubot とその代替品
  • セキュリティ
  • ベストプラクティスと最悪のプラクティス

場所: モスクワ、セバストポリホテルの会議室。

日付: 30月1日から3月XNUMX日までのXNUMX日間、大変な作業でした。

登録

出所: habr.com

コメントを追加します