運び屋 (…To Engineer Days)

Network / Cloud Native / Kubernetes / コンテナー

SRE / DevOps / Kubernetes Weekly Reportまとめ#3(2/16~2/21)

SRE DevOps Kubernetes WeeklyReport 英文技術記事まとめ 週刊

この記事は2020/2/9~2/14に発行された下記3つのWeekly Reportを読み、
各レポート内の全記事をまとめて、備忘録兼リンク集として残したものです。 誰かの参考になればと願っています。

DEVOPS WEEKLY ISSUE #477 February 16th, 2020
SRE Weekly Issue #207 February 17th, 2020
KubeWeekly #204: February 21th, 2020

  • この記事を読んで疑問点や不明点があれば、URLから本文をご確認の上、ご指摘頂ければ幸いです。

  • 理解が浅いジャンルも、とにかくコメントする様にしていますので、私の勘違いや説明不足による誤解も多々あろうかと思います。

  • 情報量が多いので文字とリンクだけに絞っております。

  • 各レポートで取り上げられている記事には2019年のものもあり、必ずしも最新のものという訳ではない様です。

DEVOPS WEEKLY ISSUE #477 February 16th, 2020

News

====

A post on organisational friction, and getting things done where work crosses team and other boundaries. Lots of examples and a useful framing of this type of problem.

  • タイトルは「SURVIVING THE ORGANISATIONAL SIDE QUEST」

  • 自身の経験、同僚のDan Na氏のプレゼンおよびスライド"organizational friction"などを使って組織内でのミスコミュニケーションの意味や、摩擦を乗り越えて目標を達成する話を展開している。

Microservices are one architectural approach, rather than the answer to all systems problems, at least according to this post on the tradeoffs and design decisions of choosing to adopt microservices.

  • タイトルは「Should I use microservices?」Considerations for when—and when not—to apply microservices in your organization.

  • Sam Newman氏のレポート「What are Microservices?」のからの抜粋記事。

  • フルバージョンはこちらから入手可能です。

  • Sam Newman氏は6月15日から18日にカリフォルニア州のSanta Claraで行われる「O’Reilly Infrastructure & Operations Conference」のco-chairを務めている。

  • マイクロサービスの適用には無数のチャレンジングな課題があり、慎重に検討する必要があると筆者は考えている。

  • マイクロサービスが上手く機能しない組織、上手く機能する組織の特徴を上げている。

  • マイクロサービスはシステムを進化させ続ける上で多くの柔軟性を与えてくれるので、もちろんコストは掛かるが、将来のシステムの変更に関わるオプションをオープンにしておくならば支払うに値するコストであると結論付けている。

An interesting discussion of the role of database migrations, looking at historical approaches and a new automated approach using GitHub Actions.

  • The GitHub Blogより、タイトルは「Automating MySQL schema migrations with GitHub Actions and more」。

  • GitHub社ではMySQLのスキーマ移行を1日あたり平均2件、日によっては6件実行している。

  • その移行作業がデータベースインフラチームに与えている多大なToilと、手動のプロセスをいかにして自動化する方法を模索してきた話。

  • DB周りは今いじっていないけれども興味深い内容なので、後で読み返す。

Most things in Kubernetes go through the API Serverer. That makes the Kubernetes audit log, which records those requests, a powerful monitoring tool. This post explores what it contains and how you can use that data effectively.

  • Datadog社の「サーバレスの現状」に対する調査レポート。タイトルは「How to monitor Kubernetes audit logs」。

  • Kubernetesのauditログを活用してクラスターを深く分析する方法を紹介しています。

A fantastically comprehensive look at what’s new in the latest Salt release. Far more than just a list of features, the post puts new capabilities in context and shows lots of examples.

  • タイトルは「What's new in Salt 3000 Neon」。

  • この記事はSalt Neonリリースの新機能の非公式な要約。 Salt Fluorineと同様に、一連のツイートとして始まり、主に新しい機能について言及している。

  • Saltは1. 構成管理システムおよび2.分散リモート実行システム。リモートノードを定義された状態に維持できる。たとえば、特定のパッケージがインストールされ、特定のサービスが実行されていることを確認できる。

  • 分散リモート実行システムとしてコマンドを実行し、リモートノードでデータをクエリするために使用される。個々のノード上で、または任意の選択基準を使用して、コマンドを照会および実行する。

  • 他の変更や廃止について（たとえば、RAETがなくなったなど）を読みたい場合は、公式リリースノートと新しい手作りの変更ログの確認を勧めている。

  • 私がそもそもSaltを全く知らず、内容を調べるのに一番時間が掛かった。

A nice migration story, moving a CI/CD pipeline from Jenkins to Concourse. Observations about improvements and expectations as well as difficulties. The fly CLI tool looks nice.

  • タイトルは「We killed the butler: Replacing Jenkins with Concourse」。

  • 文字通りJenkinsからConcourseに移行した話。

  • インフラの構成を全てgitopsで管理しようと取り組んでいる。

Infrastructure described with Terraform is still code, and applying programming techniques like refactoring to keep it maintainable is important. This post explains why and shows a few examples.

  • タイトルは「Refactoring Terraform, The Right Way」

  • 本記事は、記事の最後に載っているスライドのrecap。

  • よくある「まずは動くものを作って、時間に余裕が出来たら改善していこう」という考え方と、それに沿ったアプローチで業務を行っている所から話は始まる。

  • 上記のアプローチに課題があり、Terraformを少しユーザーフレンドリーにし、デバッグしやすくする方法が思いつかなかった筆者。

  • Yevgeniy Birkman氏のブログ「5 lessons learned from writing over 300,000 lines of infrastructure code」を見て、いかにTerraformをより堅牢で、クリーンで、使いやすくするか、何よりもいかに必要な変更や改善を行う為に必要な自信を得るかに目を向ける様になった。

Another post on writing maintainable Terraform code. Lots of examples and a seet of rules around modules, data, interpolation, state and more.

  • タイトルは「Terraform Poka-Yokes — Writing Effective, Scalable, Dynamic, and Error-Resistant Terraform」。

  • 「Poka-Yoke」って何語？と思ったら、「ポカヨケ」の事でした。面白い。

  • 筆者はSenior DevOps Engineer/SRE。

  • しばらく前に、インフラストラクチャアプリケーションパターン(I-Aパターン)と呼ばれるIaCを説明する記事を読んで感銘を受けた。その記事の6部構成のフルシリーズは、Martin Atkins氏のブログで入手可能。

  • ここでは、この記事のアイデアを広げ、I-Aパターンの他の考えられる利点や実装とを考え、ポカヨケを作成できるルールについて述べています。

This post nicely summarises why Go has made such an impact on infrastructure and cloud-based applications, outlining several of the advantages of the runtime and toolchain in particular.

  • タイトルは「Go for Cloud」。

  • この記事では、クラウドのシステムにおけるGo言語のユニークな強みと、初見のユーザーにとって落とし穴となり得る不明確な点もカバーしています。

Events

Devops Days New York is coming up on March 3rd and 4th with the usual mix of talks, ignites and open spaces. Interesting topics like lifecycle management, product management for operations teams, CI/CD pipeline sprawl and more. TIckets are available now and you can get a 15% discount with the code "devopsweekly".

  • 3月3日~4日にニューヨークで開催される「DevOpsDays NYC 2020」の案内。

Tools

Preflight is a tool for verifying a Kubernetes cluster is configured correctly using an opinionated set of Open Policy Agent policies.

  • Kubernetesのクラスターが正しく構成されているかOPA(Open Policy Agent)のポリシーを使って検証するツール「Preflight」のGitHubページ。

Host extraordinaire, Benton Rochester, talks with Gene Kim about DevOps and his excellent new book, The Unicorn Project. Don't miss this highly-anticipated episode of Ship Happens, the Splunk + VictorOps podcast:

SRE Weekly Issue #207 February 17th, 2020

Articles

You see pilot error, I see normal work

The scenario: a seemingly botched landing, a finding of human error, and retraining for the errant pilots. The author recasts the entire incident in a much more realistic light that shows that the pilots’ actions were perfectly reasonable.
Robyn Ironside — Safety Differently

  • Jetstart社のパイロットが着陸時に着陸装置を忘れてしまったとして、パイロットのミスとして結論付けられたインシデントを筆者が分析した記事。

Running servers (and services) well is not trivial

Just exactly what would it take to (reliably) run your own git server internally?
Chris Siebenmann

Trade-offs under pressure: heuristics and observations of teams resolving internet service outages

In this two part series, The Morning paper takes on John Allspaw’s master’s thesis from Lund University. Here’s part two.

Adrian Colyer — The Morning Paper (summary)
John Allspaw — Lund University (original paper)

  • Adrian Colyer氏によるCSの調査をランダムに見ていくシリーズ。2部構成でPart2も上記part twoのリンクに。

  • John Allspaw氏の2015年に発表の修士論文から。

Team Structure for Software Reliability within your Organization

The section toward the end under the heading "Things need to get worse before they get better." especially resonated with me.
Hannah Culver — Blameless

  • Will Larson氏のブログ記事「Modeling Reliability」にインスピレーションを受け、より多くの聴衆のために数式を抽象化し、信頼性のためのチーム構築を直感的に理解させる事を試みている。

Music in Resilience: The Practice of Practice

Incident response and improvisational music share a lot in common.
Matt Davis — Verica

Outages

KubeWeekly #204: February 21, 2020

The Headlines

Editor’s pick of the highlights from the past week.

Why I Contribute to the Open Source Community—and You Should Too Marky Jackson

Marky Johnson shares his journey to becoming a passionate, open-source contributor that all started with a rocket scientist. His post reminds us that open source is welcome to all and invites you to join the fun.

  • 現在Sysdig社でシニアソフトウェアエンジニアとして活躍している筆者。

  • JenkinsのPrometheusプラグインなどのコントリビューターとしてOSS活動を行なっている。

  • 次世代のエンジニアのメンタリングやスポンサー活動を行なっていて、読者にも「今日どうやって世界に違いを生み出しますか？」とコントリビュートする素晴らしさを語りかけています。

  • 半生を振り返りながら、いかにして現在の価値観や技術力に至ったのかを渡ってきた社名なども挙げながら書いていて興味深いです。

Roaring Elephant podcast: KubeCon + Cloud NativeCon EU preview

Not a regular news episode this time. Instead, we are starting our KubeCon/CloudNativeCon Amsterdam coverage and have co-chairs Vicki Cheung and Constance Caramanolis on as a guest to tell us all about these conferences. If you’ve never attended one of these, this discussion will give a good idea on what to expect and for seasoned attendees, there is a little bit of a behind-the-scenes look at how these events take form.

  • Roaring Elephant podcastで「KubeCon + Cloud NativeCon EU」のプレビューとして、co-chairのVicki CheungとConstance Caramanolisをゲストに迎えている。

  • 運営者サイドの話も少々。

The Technical

Tutorials, tools, and more that take you on a deep dive into the code.

Open Policy Agent: Microservices Authorization Simplified
Gaurav Chaware, Infracloud

  • 筆者はマイクロサービス開発の実装時に認証と認可でよく問題にぶつかる。

  • この記事ではOPA(Open Policy Agent) がいかに認可の簡素化を手助けしてくれるかについて探っていく。

Deploying Envoy and Kafka to collect broker-level metrics
Adam Kotwasinski, Workday

  • Envoy+Kafkaの2つのデプロイ方法を紹介している。

  • Kafka関連のトラフィック全てを、Envoyを介してルーティングする (クラスター内の通信も含む)

  • Kafkaクライアントのトラフィックのみを、Envoyを介してルーティングする

Introduction to SPIFFE and SPIRE Projects (Lightboard)
Evan Gilman, maintainer SPIFFE and SPIRE

  • YouTube動画でlightboard(スピーカーがペンで書きながら解説するのに使っている透明なボード)でScytale社のEvan Gilman氏がSPIFFEとSPIREの概要を説明しています。

  • 先々週、HPE社によるScylate社のM&Aのニュースを取り上げましたね。

Find an optimal set of nodes for a Kubernetes cluster

Kubecost

  • OSSであるKubecostの紹介。

  • インストールするにはこちらのページでメールアドレスを入力して登録し、Helmかマニフェストを使う。

  • 現状はGCPとAWSのクラスターをサポートしており、インストールされ次第、ワークロードのデータ収集を開始する。

GKE Node Pool Location and Surge upgrades GA

Two new Google Kubernetes Engine (GKE) features are Generally Available. Node pool location allows GKE users to specify the location for node pools independently from the location of clusters.

Surge upgrades allow users to specify the number of extra (surge) nodes and number of accepted unavailable nodes during an upgrade, improving reliability and reducing disruption to workloads.

  • GKEのGAとなった新機能Node Pool LocationとSurge upgradesの紹介。

  • 両方とも重要な機能だと思います。動かしてみたい。どちらも現行はCLIのみかな？

The Editorial

Articles, announcements, and morethatgive you a high-level overview of challenges and features.

Architecting for Multicluster Kubernetes
Thomas Rampelberg, Linkerd

  • この記事では、クロスクラスタートラフィックの信頼性、安全性、および可観測性を高めるマルチクラスターソリューションの最小要件について概説しています。

  • 後続のブログ記事では、いくつかの実装の選択肢を取り上げていくとの事。(2/22現在まだ出ていない模様)

Five Surprising Ways Enterprises Are Putting Kubernetes To Work
Murli Thirumale, Portworx (published in Forbes)

  • エンプラ企業がKubernetesを活用し、近い将来プラットフォームがどのように進化するかについての洞察を提供する5つの驚くべき(?)方法を述べています。

eBPF and Falco, with Leonardo Di Donato
Adam Glick and Craig Box, Kubernetes Podcast from Google

  • Sysdig社のOpen Source engineerであるLeonardo Di Donato氏がゲスト。

  • Leonard氏はFalco projectにフルタイムで対応している

  • LinuxカーネルのListenに使用しているeBPF(extended Berkeley Packet Filter)のアーキテクチャー、今までとこれからの使い方、Falcoで今後何が来るか？などについて語っている。

  • News of the weekは先週分も含めてKubeWeekで取り上げているニュースが多いが、そうでないものも多い。

  • 「Links from the interview」を丸ごと持ってこようと思いましたが、ニーズが分からないものに対してやり過ぎだと思ったので、やめました。上のKubernetes Podcastのリンクから興味あるものを個別に取って頂くのが良さそう。

Security concerns hampering the adoption of containers and Kubernetes
Jonathan Grieg, TechRepublic

  • 「StackRoxの調査によると、回答者の90％以上が昨年のデプロイでセキュリティインシデントを経験している」とのサブタイトルから解説がスタート。

  • 「541人の回答者に対するこの調査の結果は、クラウドネイティブの資産が安全に構築、デプロイ、実行されていることを保証しないことにより、組織がアプリケーション開発とリリースの高速化のコアメリットを危険にさらしていることを明らかにしています」など、前半は調査内容に基づく懸念や意見を述べています。

  • 最後に、コンテナサービスのプロバイダーとしてAWS/Azure/GCPのの3社、特に2位争いを繰り広げているAzureとGCPの間で競争が激しさを増していると述べています。

Google Identifies Kubernetes-Ready Storage for Anthos
Mike Melanson, The New Stack

  • Google Cloudは、Anthos Managed Kubernetes機能セットを拡張し、Anthosオンプレミスの特定の標準セットを満たすストレージパートナーを識別する資格としてAnthos Ready Storageを追加した。

  • 現在承認されたパートナーには、 Dell EMC、HPE、NetApp、Portworx、Pure Storage、およびRobin.ioが含まれている。

  • GCPのプロダクトマネージャーであるManu Batraは、ブログの記事で、各ストレージパッケージがオンプレミスでAnthosと連携するために満たさなければならない3つの主要な基準を特定している。

Managed Kubernetes Services Make K8s Simple for Platform Teams and App Developers
Emily Omier, The New Stack

Linux Foundation study throws the open-source sustainability debate into question
Matt Asay, TechRepublic

  • 「オープンソースの開発者が高い報酬を得る傾向がある」事が、最近のLinux Foundationレポート（PDF）から結論となり得るものの1つとして導き出された。

  • このレポートでは、200の最もアクティブなオープンソースプロジェクトのトップメンテナーの75％以上が、オープンソースのフルタイムまたはパートタイムでの仕事に対して報酬が支払われていることが分かった。

  • Linux Foundationは、詳細を得るために何千人もの開発者を対象としたより包括的な調査を展開中。

  • 筆者は重要なのは現金だけではないことも同様に確信している。そして、「オープンソース開発を(おそらく)経済的に持続可能である様に、感情的にも持続可能なものにするためにもっと多くのことをする必要である」と締めくくっている。

Webinar Registration

気になるWebinarが登録してチェックを。以下は今週ピックアップされていたものです。

Helm Security – a Look Below Deck
Matt Farina, Helm Maintainer @Samsung SDS
Hayley Denbraver, Developer Advocate @Snyk
Raghavan "Rags" Srinivas, Lead Container Developer Advocate @Snyk
Member webinar
Feb 25, 2020 10:00 AM Pacific Time
REGISTER NOW »

Managing Observability in Modern Apps – Microservices

Ran Ribenzaft, co-founder of and CTO @ Epsagon
Member webinar
Feb 26, 2020 10:00 AM Pacific Time
REGISTER NOW »

From Notebook to Kubeflow Pipelines with MiniKF & Kale
Vangelis Koukis, CTO & Founder @Arrikto
Stefano Fioravanzo, Software Engineer @Arrikto
Member webinar
Feb 27, 2020 9:00 AM Pacific Time
REGISTER NOW »

Kubernetes Security Best Practices for DevOps
Frédéric Harper, Senior Developer Advocate @DigitalOcean
Member webinar
March 3, 2020 10:00 AM Pacific Time
REGISTER NOW »

What’s New in Linkerd 2.7
Linkerd team
Project webinar
March 6, 2020 10:00 AM Pacific Time
REGISTER NOW »

Kubernetes Security Best Practices for DevOps
Connor Gorman, Principal Engineer @StackRox
Member webinar
March 11, 2020 10:00 AM Pacific Time
REGISTER NOW »

Welcome to CloudLand! An Illustrated Intro to the Cloud Native Landscape
Kaslin Fields, Developer Advocate @Google
Ambassador webinar
March 13, 2020 10:00 AM Pacific Time
REGISTER NOW »

How to migrate a MySQL Database to Vitess
Liz van Dijk, @PlanetScale
Project webinar
March 20, 2020 10:00 AM Pacific Time
REGISTER NOW »

Argo CD, Flux CD and the GitOps Revolution
Jay Pipes Principal, Open Source Engineer @Amazon Web Services
Member webinar
March 24, 2020 10:00 AM Pacific Time
REGISTER NOW »

Best Practices for Deploying a Service Mesh in Production: From Technology to Teams
Buoyant
Member webinar
April 8, 2020 10:00 AM Pacific Time
REGISTER NOW »

Kubernetes 1.18
Kubernetes team
Project webinar
April 23, 2020 9:00 AM Pacific Time
REGISTER NOW »

Pivoting Your Pipeline from Legacy to Cloud Native
Tracy Ragan, CEO of DeployHub and CDF Board Member
Member webinar
June 30, 2020 10:00 AM Pacific Time
REGISTER NOW »

いかがでしたか？気になる記事や情報はありましたか？

私もまだ内容を咀嚼出来ていないものが多々ありますので、この備忘録兼リンク集を活用しながら理解を深めていきたいた思います。

では、また。

Bye now!! Yoshiki Fujiwara

SRE / DevOps / Kubernetes Weekly Reportまとめ#2(2/9~2/14)

SRE DevOps Kubernetes WeeklyReport 英文技術記事まとめ 週刊

この記事は2020/02/9~2/14に発行された下記3つのWeekly Reportを読み、
各レポート内の全記事をまとめて、備忘録兼リンク集として残したものです。 誰かの参考になればと願っています。

DEVOPS WEEKLY ISSUE #476 February 9th, 2020
SRE Weekly Issue #206 February 10th, 2020
KubeWeekly #203: February 14th, 2020

  • この記事を読んで疑問点や不明点があれば、URLから本文をご確認の上、ご指摘頂ければ幸いです。

  • 理解が浅いジャンルも、とにかくコメントする様にしていますので、私の勘違いや説明不足による誤解も多々あろうかと思います。

  • 情報量が多いので文字とリンクだけに絞っております。

  • 各レポートで取り上げられている記事には2019年のものもあり、必ずしも最新のものという訳ではない様です。

DEVOPS WEEKLY ISSUE #476 February 9th, 2020

News

====

The first post in a series summarising the team topologies book. Good points about Conway’s law, designing handoffs, communication overhead and more.

  • タイトルは「Team Topologies Book Summary – Part 1 of 3: Key Concepts」

  • IT Revolution社が出版した最新の著書「Team Topologies」の要約記事の1/3回目。

  • IT Revolution社は「The Phoenix Project」の共著者であり、「The Unicorn Project」の著者であるGene Kimが創立。

  • 「Team Topologies」はMatthew Skeltonと Manuel Paisが共著者。2人は「DevOps Topologies」というウェブサイトを運営している。

  • コンウェイの法則、ダンバー数、タックマンモデル、認知負荷など法則やモデルなどを使ってチームのあり方、運営方法を説明しています。

  • タックマンモデルを調べていたらチーミングモデルに行き着いたり、コンウェイの法則で先日参加したGoogle Cloud Anthos Dayのセッションで話題に上がった逆コンウェイ戦略が思い浮かぶなど、それぞれのアイデアが繋がっていく感覚がありました。

  • 2/3、3/3回目(つまり、Part2とPart3)も既にリリースされていて、同じページのリンクから見れるので良ければどうぞ。

In the context of incident management, this post makes the argument that (just) counting production incidents can have negative side effects.

  • タイトルは「Stop Counting Production Incidents」。

  • インシデント数を元にした対応が有効ではなく、有害になり得る事を述べています。

  • インシデント数を言い訳にしない、安易にインシデント数を実際のカスタマーエクスペリエンスを反映したメトリックを取って計測するなど、筆者のFacebook時代の経験を交えてタイトルに沿って説明がなされていきます。

A presentation looking at the best way to structure Terraform code, and how those practices are based on the evolution of the language and tooling.

  • 筆者がベルギーのGhentで2/3 - 2/5開催された cfgmgmtcamp(Config Management Camp)2020で「Terraform Without The Mess」と題して話した内容のスライド紹介。

  • Terraformの機能の歴史がいかに今日のTerraformの構成を組み、書いているか。そして、変更をシンプル、予測可能かつ安全にモダンなTerraformコードをいかにして書くべきかを筆者自身の意見を盛り込んだ提案をしています。

  • レコーディングが無かったが、いくつかスライドデックに資料を上げる様にリクエストをもらったので、アップしたとの事。

  • Infrastructure as Codeではなく、Infrastructure as Softwareという考え方。

A look at the key metrics to monitor when working with AWS Lambda applications.

  • Datadog社の「サーバレスの現状」に対する調査レポートのPart 1:"Key metrics for monitoring AWS Lambda”。

  • 図が充実してわかりやすく。流石Datadogという印象です。

  • Part 2: Tools for collecting AWS Lambda data、Part 3: Monitoring AWS Lambda with Datadogもありますので、よければ併せてどうぞ。

YAML is used in lots of places at the moment, but most YAML documents use a small subset of the language. This presentation explores some of the more powerful features.

  • タイトルは「yaml magic」。yaml magicについて語り、「こうした魔法は楽しいが、プロダクト環境からは遠ざけておく事をオススメ」しています。

  • そして、jsonnetに辿り着く。

A look at approaches to quantifying risk, why it’s useful in a security context and a Python library to get started with.

Tools

K14s is a set of Kubernetes Tools that follow Unix philosophy to be simple and composable. Templating, application management, image management and more.

  • K14sは、「Kubernetes Tools」の略。Kとsの間にスペースを含めて14文字が入っているので、こう呼ばれている。

  • Unixの哲学に従い、シンプルで組み合わせ可能である。

  • GitHubのページはこちら。

Dekorate is an interesting approach to managing Kubernetes configuration, moving the definition into annotations in your Java code and generating the required manifests.

L2i is a handy looking tool for working with Lambda layers. It makes it easy to view the details of individual layers as well as export their content for analysis.

  • The Lambda Layer Inspector (L2I)の紹介。

  • １もしくは複数のAWS Lambda Layerをlayer ARN(Amazon Resource Name)を使って検査するCLI。

Host extraordinaire, Benton Rochester, talks with Gene Kim about DevOps and his excellent new book, The Unicorn Project. Don't miss this highly-anticipated episode of Ship Happens, the Splunk + VictorOps podcast:

  • Newsの最初に登場したIT Revolution社Gene Kimが著書である「The Unicorn Project」、絶え間なく変わるDevOpsの景観、マネージャーがエンジニアチーム内の文化的な問題にいかに取り組む事が出来るか、今日の複雑なクラウドベースの世界でいかに高速で回復力のあるCI/CDパイプラインを作り上げるかなどを埋め込まれているPodcastで語っています。

  • 余談ですが、先日splunkの方にお会いしたので元となるDevOps Weeklyなどの情報発信の感謝を伝えました。

SRE Weekly Issue #206 February 10th, 2020

Articles

Awakening the Sleeping Mind

All the plans in the world can’t prepare us for every incident, and yet we can excel during incidents anyway. How?

Will Gallego

  • フィクション及びサイエンスフィクション小説好きの筆者が「The Kingkiller Chronicle」の魔法システムである「ネーミングの研究」を題材に話を展開していく。

  • たとえ話と同じく、ソフトウェアエンジニアリングでは事前の予測を重要視しがちだが、物事が発生した時に素早く認識し、素早く反応し、その動向と自身の動き方を学ぶ事の重要性を説いている。

Pilot Declares Emergency Because Of Extreme Hypoxia

These pilots’ minds were almost literally sleeping. The air traffic controller gave them a command they could execute in their sleep: Descend and Maintain.

  • YouTubeのリンクが貼られていて、動画がスタートします。いきなり音声が流れてくるので、私も不意を突かれました。

  • 飛行機のパイロットが低酸素症により意識を失いかけ、管制塔のスタッフが素早く原因を究明し、フォローする話。

In Flight Emergency – Pregnant Pilot Brake Failure!

Along the same lines an incident caused this pilot to nearly forget how to fly, and yet she safely landed the plane with some reassurance by the ATC.

  • またまたYouTubeのリンクが貼られていて、動画がスタートします。

  • つま先ブレーキが故障してしまった妊娠中のパイロットの方と管制塔のスタッフのトラブルシューティングから着陸後までのやりとり。

  • 乗っているのはパイパー・エアクラフト社の軽飛行機「チェロキー」かな。

Ten challenges for making automation a ‘team player’ in joint human-agent activity

Today’s choice looks at what it takes for machines to participate productively in collaborations with humans.

Adrian Colyer — The Morning Paper (summary)

Klein et al. — IEEE Computer Nov/Dec 2004 (original paper)

  • 人間と機械が効果的な共存関係を築くには、文中にある「10のチャレンジ」の要件を満たすAgent(人間的にタスクを行うプログラム?)が必要との事。

Rehabilitating "you can’t manage what you can’t measure"

A lot of things that are happening in your organization, your system, are largely invisible. And those things, that work, is keeping things up and running.

Lorin Hochstein

  • タイトルの「自身が計れぬモノをマネージメントする事は出来ない」という議論の分かれる格言に対して、筆者は「2通りの解釈がある」として論を展開する。

Heroku Incident 1951 followup

This followup covers incidents on January 22 and 24.

  • 1/22 21:40 UTCから1/24 8:04 UTCの間に発生したHerokuのlogging関連の機能の不具合に関するフォローアップレポートと、ステータス情報。

Stop Counting Production Incidents

Tracking the number of incidents is almost never going to be useful, and is likely to be detrimental.

Rick Branson

  • 上記のDEVOPS WEEKLY ISSUE #476で触れているので割愛します。

Low hanging BCP and DR scenarios – UnixDaemon: In search of (a) life

Some good scenarios to think about, including an idea for chaos engineering with humans.

Dean Wilson

  • 筆者がクリスマスの直前に新たなBCP、DRの書類作成を行う必要が出た為、準備としてTwitterでいくつかの簡単なオープンシナリオを公開し、コメントを収集した。

  • 後世の為に自身の外部記録としてバックアップをこの記事に投稿した。

Outages

Chef Supermarket
Twitter
Search in Windows 10
->Included searching of local content.
Buffer
EMIS
->EMIS is an IT system used by health care services across the UK.
Vimeo
Ticketmaster NFL Game Pass
Microsoft Teams
* 上記各社の障害情報。

KubeWeekly #203: February 14, 2020

The Headlines

Editor’s pick of the highlights from the past week.

Full steam ahead with 2020 KubeCon + CloudNativeCon events!

Novel Coronavirus Update: The Linux Foundation is continuously monitoring the Novel Coronavirus situation to ensure the safety of our event participants and staff. We will be following all recommended guidelines from the Centers for Disease Control and Prevention (CDC) and the World Health Organization (WHO) as the situation progresses.

Despite the cancellation of MWC Barcelona, many other significant conferences are still occurring and we have no plans to cancel KubeCon + CloudNativeCon Europe.

  • CNCFとして現在は以下の認識を持っている事を表明。

  • イベント来場者とスタッフの安全の為、新型コロナウィルスの動向を注意深く見守っている事

  • Disease Control and Prevention (CDC) 、the World Health Organization (WHO) のガイドラインに従っている事

  • MWC Barcelonaのキャンセルにも関わらず、多くの重要なカンファレンスが引き続き開催される予定であり、KubeCon + CloudNativeCon Europeをキャンセルする予定は無い

Childcare: It’s Good for Everyone

Yes – there is childcare at all KubeCon + CloudNativeCon events. Emily writes a great blog on her, and her daughter’s experience with childcare at the event.

If you would like to sign up for this service at KubeCon + CloudNativeCon Amsterdam, please complete this RSVP form by February 24, 2020, 5:00 PM PDT.

Emily Omier, The New Stack

  • KubeCon + CloudNativeConのChildcareオプションへの言及。

  • 筆者は少なくとも、あと10年はカンファレンス(あるいは出張)でChildcareの様な環境は疑いの余地も無く、得られないであろうと予想していた。

  • KubeConのオンサイトChildcareはハイクオリティーでお金に変えがたい価値がある。申し込みも不要。KubeCon参加者なら誰でも利用可。

  • 私も素晴らしい取り組みだと思います。私も何か人の可能性を生かす動きや提案が出来れば。

The Technical

Tutorials, tools, and more that take you on a deep dive into the code.

Config Sync for GKE

Config Sync allows cluster operators to manage single clusters, multi-tenant clusters, and multi-cluster Kubernetes deployments using files, called configs, stored in a Git repository.

  • GKEのConfig Syncの説明。

Calico for Kubernetes networking: the basics & examples

Flant staff

Use Kubeflow, Rook and Istio to build an AI integrated development and delivery platform

Vanilla Kola

Docker Donates the cnab-to-oci Library to cnab.io

Silvin Lubecki, Docker

  • Docker社が「cnab-to-oci」ライブラリーをcnab.io(CNAB project)に寄贈した話。

  • CNAB(Cloud Native Application Bundle)プロジェクトは、去年Microsoft社とDocker社がCNABの仕様をLinux FoundationのJoint Development Foundationに移管した際には創立された。

Azure Kubernetes (AKS) Security Best Practices Part 2 of 4

Karen Bruner, StackRox

  • タイトルの通り、AKS Security Best PracticeのPart 2。

  • AKSクラスターのネットワークインフラと、そのネットワークを外部のアタック及びクラスターワークロードの内部の設定ミスから保護する為にロックダウンする提案。

  • 以下の項目にて説明。一つずつ実際に構成を考えたり、設定しながら見直したい。

  • ゼロトラストの原則

  • ノードのSSHアクセスの制限

  • Kubernetes APIへのネットワークを介したアクセスの制限

  • VMインスタンスのメタデータへのPodのアクセスをブロックする

  • クラスターの外部向け通信を制限する

  • HTTPアプリケーションルーティングを無効化する

  • サービスメッシュを適用する

Rolling Updates and Blue-Green Deployments with Kubernetes and HAProxy

Nick Ramirez, HAProxy

Unit 42 CTR: Leaked Code from Docker Registries

Jay Chen, Palo Alto Networks

  • DevOpsのプラクティスに焦点を合わせて、クラウド内のどこに設定ミスが発生しているかを判断するレポート「Unit 42 Cloud Threat Report: Spring 2020」から。

  • 記事の中で、設定ミスがあるDockerレジストリーが機密情報を漏洩を引き起こし、全面的な情報漏洩をもたらし、業務中断をもたらす可能性がある事を示しています。

Understanding Kubernetes Storage – Stateful, Stateless, POSIX + REST

Nitish Tiwari, Minio

  • Kubernetesの採用が増大するにつれ、Kubernetes上のストレージパターンも増大してきた。

  • Kubernetesのストレージパターンとステートレス vs ステートフルコンテナーの議論に取り組み、違いとなぜそれが重要なのかを理解することをゴールとしている。

  • 「これらのコンセプトを理解するには自身で試してみるのが一番」...ですよね。MinIO触ってみよう。

Load balancing and scaling long-lived connections in Kubernetes

Daniele Polencic, learnk8s.io

  • 先週の記事で取り上げていますので、ここでは割愛します。

The Editorial

*Articles, announcements, and morethatgive you a high-level overview of challenges and features. *

End-of-life announcement for CoreOS Container Linux

  • May 26, 2020にCoreOS Container LinuxがEOLを迎える。ユーザー各位にはなるべく早い他のOSへの移行を強く勧めている。

  • 最後にCoreOSチームとして、長年に渡りCoreOS and Container Linuxにコントリビュートして頂いたユーザー、パートナー、アドボケートの方々に謝辞を述べています。特にRackspace、DigitalOcean、Azureの草創期のサポートとGeoff Levand氏の ARM64ポートに対するコントリビュートに。

EKS vs GKE vs AKS – Evaluating Kubernetes in the Cloud

Karen Bruner, StackRox

  • 「EKS vs GKE vs AKS」という構図でクラウドベンダー3社のマネージドKubernetesを比較した記事。

  • General information、Service Limits、Networking + Security、Container Image Servicesという項目で比較。

  • 料金の比較、パフォーマンスの違いなどは条件やベンチマークなどによる差分が大きいので本記事では触れていません。

  • 本記事の情報は公開時(Feb 10, 2020)のスナップ情報と捉えて頂いて、各社の情報を定期的に確認して頂きたい。

Demystifying DevOps: Essential Building Blocks of a DevOps Approach

Catherine Paganini, Kublr

  • ビジネスリーダーにITのコンセプトを説明するCatherine Paganini氏の連載中のシリーズ から。一つ前の記事はこちら。この記事のPart 1はこちら。

  • ビジネスリーダー向けに「DevOpsは文化の変化に関するもの」などのメッセージを文字情報を中心に一部で図を使って説明している印象。

Kubernetes: 6 secrets of successful teams

Kevin Casey, Red Hat

  • Kubernetesのプロダクション環境での稼働を成功させ、ハイパフォーマンスを実現をするチームとして重要な6つの事を2ページに渡って説明。

Kubernetes Container Management Is Not Application Management

Kevin Crawley, Container Journal

  • タイトルに沿って、「アプリケーションの管理はコンテナーの管理とは無数の点で違うので、混同し無いように」とのアドバイスからスタート。

  • 結論、「Kubernetesでオーケストレーションされた環境の可観測性をサポートする最新のアプリケーション監視ソリューションを使用する事」+「常にアプリケーションのパフォーマンスを注視する事」。

Announcing Linkerd 2.7: External PKI support, better gitops workflows, streamlined cert rotation, and more

William Morgan, Linkerd

  • Linkerd 2.7がリリース！今回はセキュリティーfをテーマとしたリリース。以下の更新。

  • Linkerdの相互TLSインフラの外部証明書発行者(Vault、cert-managerなど)との統合

  • ダッシュボードの改善

  • その他多数

Istio security bug found, quickly squashed

Dan Meyer, SDxCentral

  • Istioのセキュリティーの「critical」レベルのバグ、CVE-2020-8595の説明。

  • Istioコミュニティーで早急にパッチ配布を行った。

  • 攻撃者が認証トークン無しで、情報に非認証アクセスが出来てしまう認証ポリシー上のバグ。

Supporting developers as they scale: a free Kubernetes eBook

Digital Ocean

3 tips to keep Kubernetes safe at scale

Jonathan Grieg, TechRepublic

  • 大規模環境でKubernetesのセキュリティー能力を生かす3つの方法(RBAC/セキュアではないコードのチェック/公開されているポートのチェック)を紹介。　

Webinar Registration

気になるWebinarがあれば登録してチェックを。以下は今週ピックアップされていたものです。

Kubernetes Storage In Action
Sheng Yang, Senior Engineering Manager @Rancher Labs
Member webinar
Feb 18, 2020 10:00 AM Pacific Time
REGISTER NOW »

kube-scan & the K8s Common Configuration Scoring System (KCCSS) Octarine
Member webinar
Feb 19, 2020 10:00 AM Pacific Time
REGISTER NOW »

OAM: A Team-Centric App Model for Application Developers and Operators
MacKenzie Olson, Program Manager @Microsoft
Member webinar
Feb 20, 2020 9:00 AM Pacific Time
REGISTER NOW »

Helm Security – a Look Below Deck
Matt Farina, Helm Maintainer @Samsung SDS
Hayley Denbraver, Developer Advocate @Snyk
Raghavan "Rags" Srinivas, Lead Container Developer Advocate @Snyk
Member webinar
Feb 25, 2020 10:00 AM Pacific Time
REGISTER NOW »

Managing Observability in Modern Apps – Microservices
Ran Ribenzaft, co-founder of and CTO @ Epsagon
Member webinar
Feb 26, 2020 10:00 AM Pacific Time
REGISTER NOW »

Getting Started with Containers and Kubernetes
Frédéric Harper, Senior Developer Advocate @DigitalOcean
Member webinar
March 3, 2020 10:00 AM Pacific Time
REGISTER NOW »

Kubernetes Security Best Practices for DevOps
Connor Gorman, Principal Engineer @StackRox
Member webinar
March 11, 2020 10:00 AM Pacific Time
REGISTER NOW »

Welcome to CloudLand! An Illustrated Intro to the Cloud Native Landscape
Kaslin Fields, Developer Advocate @Google
Ambassador webinar
March 13, 2020 10:00 AM Pacific Time
REGISTER NOW »

Argo CD, Flux CD and the GitOps Revolution
Jay Pipes Principal, Open Source Engineer @Amazon Web Services
Member webinar
March 24, 2020 10:00 AM Pacific Time
REGISTER NOW »

Pivoting Your Pipeline from Legacy to Cloud Native
Tracy Ragan, CEO of DeployHub and CDF Board Member
Member webinar
June 30, 2020 10:00 AM Pacific Time
REGISTER NOW »

いかがでしたか？気になる記事や情報はありましたか？

私もまだ内容を咀嚼出来ていないものが多々ありますので、この備忘録兼リンク集を活用しながら理解を深めていきたいた思います。

では、また。

Bye now!!

Yoshiki Fujiwara

SRE / DevOps / Kubernetes Weekly Reportまとめ#1(2/2~2/8)

SRE DevOps Kubernetes WeeklyReport 英文技術記事まとめ 週刊

この記事は2020/2/2~2/8に発行された下記3つのWeekly Reportを読み、
各レポート内の全記事をまとめて、備忘録兼リンク集として残したものです。
誰かの参考になればと願っています。

DEVOPS WEEKLY ISSUE #475 February 2nd, 2020
SRE Weekly Issue #205 February 3rd, 2020
KubeWeekly #202 February 7, 2020

  • この記事を読んで疑問点や不明点があれば、URLから本文をご確認の上、ご指摘頂ければ幸いです。

  • 理解が浅いジャンルも、とにかくコメントする様にしていますので、私の勘違いや説明不足による誤解も多々あろうかと思います。

  • 情報量が多いので文字とリンクだけに絞っております。

  • 各レポートで取り上げられている記事には2019年のものもあり、必ずしも最新のものという訳ではない様です。

DEVOPS WEEKLY ISSUE #475 - 2nd February 2020

News

For lots of people in large organisations, the CIO is the top role on the IT side. But the expectations, and the environment, are changing. This post explores the changing role of the CIO in response.

  • 新たな種類のテックリーダーとしてのCIOにモダンなビジネスが求めるものを、3つの全体的なトランフォーメーションにおけるベクトルと、変革を起こすCIOの5つの特徴を軸に話しています。

A good talk on Kubernetes security, dipping into several tools but mainly showing the nature of a few specific exploits and giving tips to avoid common problems,

  • いかにセキュアに(あるいはセキュアではない)コンテナ化について、記憶に残りやすい大量のイメージと共に説明しています。

The start of a series of posts implementing a container manager/runtime, in order to better understand the relationship between high-level tools like Kubernetes and the containers that run on the operating system.

  • container manager(ランタイムインスタンスなど複数のものを制御するハイレベルのコンポーネントを筆者は呼んでいる)conmanの紹介を中心とした記事。デモあり。

A collection of 30 of the best technical talks from last year. Topics range from building reliable services to low-level linux features and global traffic management to testing in production.

  • 筆者が2019年の技術的なトークベスト30をまとめたもの。各トーク動画のリンクが 貼られていて、気軽に確認できます。そして、選ばれているだけあって良質なプレゼンばかりで、自身が詳しくないジャンルも聴きたくさせるものがあり、大変参考になります。

A look at some of the patterns of container evolution, in particular exploring the rise of microVMs, unikernels and container sandboxes.

  • 現状のコンテナの課題と将来について。将来に向けてMicroVMs、Unikernels、Container sandboxesを紹介。

A nice walkthrough of installing Cloud Foundry on Kubernetes, looking at the different tools available to do the job.

  • Cloud FoundryをKubernetes上で動かすツールとしてcf-operator、 Cloud Foundry Quarks、 Eirini、kubecfを紹介。kubecfの「今後に乞うご期待」といった感じのデモを行っています。

Jobs

Hiring DevOps engineers in Berlin & remotely, Arweave is a permanent information storage network, built on a new type of blockchain called a blockweave. They're working to solve the problem of the ‘memory hole’, as formulated by George Orwell in Nineteen Eighty-Four, by building the first data storage medium that truly never forgets. Arweave works by rewarding network participants for contributing hard disk space to the network, in a similar fashion to proof of work in Bitcoin and other cryptocurrencies. Contact jobs@arweave.org or apply at:

  • Stack Overflow上での採用情報ですね。Arweave社がDevOps職をベルリンで募集。

Tools

Rode looks like an interesting software supply chain tool. It provides for the collection, attestation and enforcement of policies, supported by Grafeas and Open Policy Agent.

  • Rodeの紹介。OPA(Open Policy Agent)とGrafeasがサポートするポリシーの収集、認証、実行を行うソフトウェアのサプライチェーンツールの様なもの。README.mdの図解が見やすい。

Service resilience requires both real-time incident response software and a robust incident management and IT ticketing tool. These common techniques and tools can help you enhance your VictorOps and ServiceNow integration – making incident management suck less:

  • VictorOpsとServiceNowのサービス連携の紹介。内容から見て2つのサービスの「統合」というよりも「連携」。Splunkの自社グループプロダクト(VictorOps)のSNOW連携紹介といった方がわかりやすいか。

  • 余談ですが、最近身近で聞こえてくる「ServiceNowをSNOWって略すのなんで問題」が英語でも上がっていて笑った。

SRE Weekly Issue #205 3rd February 2020

Articles

The Myth of the Blameless Retrospective

This article hints at the fact that blame and sanction (punishment) are two different things.

Bonus content: Dr. Richard Cook on blameless vs sanctionless retrospectives

Bob Reselman

  • SRE本にある「非難なきポストモーテム」と対比して「非難なき振り返りの神話」と題して書かれている記事。この文化が生きるのはGoogle、Etsy、そしてAirbnbなどの一部の会社に限られる。

  • 多くのIT企業ではレガシーなコードや文化であり、適用が困難。会社は非難する矛先を探している事を受け入れて、神話ではなく現実を生きろと説いています。

  • 盲目的に違う文化を取り入れようとする人々への牽制かな。

(A few) Ops Lessons We All Learn The Hard Way

here we have a few lessons in operations that we all (eventually) (have to) learn; often the hard way.

Jan Schaumann

  • 運用上の教訓が88個並べられていて、味わい深いです。

What are Service Level Objectives (SLOs)? Lessons Learned

I especially like the emphasis on reducing pager fatigue through thoughtfully selected SLOs.

Emily Arnott — Blameless

  • SLO(Service-Level Objective)s のメリットについて述べています。

Resilience Roundup – Four concepts for resilience and the implications for the future of resilience engineering

The four concepts, drawn from a paper by Dr. David Woods, are:

  • Rebound

  • Robustness

  • Graceful extensibility

  • Sustained adaptability

Thai Wood — Resilience Roundup

  • resiliency(回復性)についてのDr.David Woodsの記事をまとめて解説したもの。回復性を上記の4つのコンセプトにカテゴリー分けして説明。

How an Alleged "Space Strike" Beautifully Demonstrates Work-As-Imagined Versus Work-As-Done

Understanding the difference between work-as-imagined and work-as-done is critical to the reliability of a complex system.

Jaime Woo and Emil Stolarsky — The Morning Mind-Meld

  • NASAのミッション中に起きた90分の沈黙、「宇宙での反乱」と称された事件を題材に語っています。

  • 労働環境などに語っていますが、個人的には中々ピーンと来ず。なぜここに？
    ->「 NASAの件は、複雑なシステムを継続して運用するには絵に描いた餅ではなく現実的な設計をしないと運用が破綻する、という話では」「reliabilityを維持するための重要な観点を得られる話だと個人的には思いました！」との指摘を頂き、読み直しました。

  • 指摘頂いた通りの文脈で語られており、私の中で話が繋がらず読み込めていなかったのだと反省しました。おかげさまで理解が深まりました。@inductorさん、ありがとうございます!!

Tracking toil with SRE principles

There’s a useful survey in here if you’re trying to measure or track toil in your organization.

Eric Harvieux — Google

  • SREの原則にそってToilを定義し、追跡する方法の紹介。

  • 技術的/組織的な複雑性をToilとしない。

  • 先日TwitterのTLに流れてきたのでRetweet/読了済みでした。

Site Wide Memory Leak: An On-Call Story

A nice little debugging story hinging on a bug in an upstream library.

Sanket Patel

  • とあるオンコール当番の週末に異なるホストから頻繁にアラートを受け取るところから話が始まる。

  • 「メモリー使用率閾値超え」のアラートを引き起こしたMemory Leakと、その原因を突き止めて知見を得た週末

Outages

Pinterest
Microsoft Office 365 Sharepoint Online
TD Bank
Google Drive, Docs, Sheets, and Slides
Facebook and Instagram
Gandi
->They posted a quite candid analysis, concluding that they’re not sure what went wrong.
* 上記の各社障害情報。Gandi社はありのままのポストモーテムが読めて興味深いです。

KubeWeekly #202: February 7, 2020

The Headlines

*Editor’s pick of the highlights from the past week. *

Congratulations to the newest TOC members!

Please help us in welcoming the newest members of the CNCF TOC including Katie Gamanji, Liz Rice, Saad Ali, Sheng Liang, and Justin Cormack.

Announcing the containerd Project Journey Report

CNCF

CNCF just released the containerd Project Journey Report, the fourth such report issued for CNCF graduated projects. This report attempts to objectively assess the state of the containerd project and how CNCF has impacted the progress and growth of containerd.

  • CNCFとしてGraduatedプロダクトに対する4つ目となるレポート、 CNCF containerd Project Journey Reportをリリース。

  • containerdの現状とCNCFが発展と成長にどの様にインパクトを与えたのか客観的に評価を試みた。

The Technical

*Tutorials, tools, and more that take you on a deep dive into the code. *

How to Develop and Debug Python Applications in Kubernetes with Okteto

Ramiro Berrelleza, Okteto

DNS Lookups in Kubernetes

Karan Sharma, Zerodha

  • KubernetesにおけるDNSの仕組みを解説。現在のバージョンのデフォルトのCoreDNSを軸に。

Continuous Profiling Go applications running in Kubernetes

Gianluca Arbezzano, InfluxDB

  • 筆者は先日"Continuous profiling in Go with Profefe”という記事を書き、Continuous profiles infrastructure(コレクター、リポジトリ、保存用API、プロファイルの検索、クエリー)を提供する新しいOSSであるProfefeを紹介。筆者もコントリビュートしている。

  • 上記記事により情報が載っているが、気にせずこの記事をこのまま読んでもらって構わない模様。

A bit of Istio before tea-time

Alex Ellis, OpenFaaS

  • Istioのデモ(パブリックIPアドレス、自身のラップトップ利用)がティータイム程度の短時間で実行可能。

Latest Jepsen Results against etcd 3.4.3

Xiang Li, Alibaba Group

  • Jepsen社がetcd 3.4.3をテストと分析を行い、良い結果や有益なフィードバックをetcdのチームに共有を行った。

  • レポート全体を見たい場合はこちらから。

Konveyor: Open Source, Migration Assistance for Kubernetes

Konveyor Project

  • 既存のアプリをKubernetesに移行するOSS Konveyorの紹介。

  • シンプルな説明とGitHub、Forum、Slack、Get Startedのリンク。Get Startedは作りかけかな？

Troubleshoot Kubernetes with the power of tmux and kubectl

Abhishek Tamrakar, Opensource.com

Load balancing and scaling long-lived connections in Kubernetes

Daniele Polencic, LearnK8s

  • Kubernetes上で提供されていないlong-lived connectionsのスケールと負荷分散をする方法の提案

Emit Datadog monitors based on Kubernetes state

Astro is an operator that emits Datadog monitors based on Kubernetes state.

The Editorial

*Articles, announcements, and morethatgive you a high-level overview of challenges and features. *

GitLab, with Marin Jankovski

Craig Box and Adam Glick, Kubernetes Podcast from Google

  • Google社のメンバーが基本毎週ホストしているKubernetes Podcast。

  • GitLab社のEngineering ManagerであるMarin Jankovskiがゲスト。

  • News of the weekは先週分も含めてKubeWeekで取り上げているニュースが多いかな。

HPE acquires zero-trust networking, security firm Scytale

Charlie Osborne, ZDNet

  • HPE(Hewlett Packard Enterprise)社のScytale社の買収。

  • HPE社の発表はこちら。SPIFFE Meetupに過去2回参加している事もあって興味深い。ゼロトラストネットワーキングは理解を深めていきたいジャンル。

Run Windows Server Containers on GKE

Tim Anderson, The Register

Kubestone – Kubernetes & OpenShift performance benchmarking

Kubestone is a benchmarking Operator that can evaluate the performance of Kubernetes installations.

  • Kubernetes上のインストールにおけるパフォーマンスのベンチマークに使用するオペレータ、Kubestoneの紹介。

  • 件名にOpenShift入っているけれども、本文と資料での言及が見当たらず。。。

Kubernetes’ Inevitable Takeover of the Data Center

Scott Fulton III, DataCenter Knowledge

  • DCK(Data Center Knowledge)として、Kubernetesをデーターセンターに取って代わる最も破壊的なテクノロジーと捉え、登場と過去数年の動向を注意深く分析した特集。

If You’ve Got It, Flaunt It — Kubernetes Experience, That Is

Sydney Sawaya, SDxCentral

  • Kubernetesを扱えるエンジニアの需要と、供給のギャップとCNCFのトレーニングについて軽く触れている

  • タイトルでは「Kubernetesの経験、スキルを獲得すると誇示したくなるもの、状況である」という事を筆者の表現で伝えている。

Kubernetes Operators: 4 facts to know

Kevin Casey, The Enterprisers Project

  • 真の自動化を知ってこそコンテナの全ポテンシャルを悟る事ができる。そこでKubernetesのOperatorが役割を増してきている。

  • ITリーダーとしてOperatorに関して知っておくべき4つの事を述べている。

Register Now: KubeCon + CloudNativeCon EU Day Zero Events

Kim McMahon, CNCF



How Frame.io Built a Full Security Program Around Its Video Cloud with Falco

CNCF

  • Frame.ioがいかにFalcoを使ってNetFlix、Fox Sportsなどの最も優れた映像 / 映画のクリエイターが利用するプラットフォームを作ったのか。

  • 事例の詳細はこちら。


いかがでしたか？気になる記事はありましたか？ 私もまだ内容を咀嚼出来ていないものが多々ありますので、この備忘録兼リンク集を活用しながら理解を深めていきたいた思います。

では、また。

Bye now!!

Yoshiki Fujiwara

GNS3でネットワーク技術のトレーニングメニューを作ってみた際に苦戦したこと(vlan database)

GNS3 ネットワーク VLAN

これは エーピーコミュニケーションズ Advent Calendar 2019 の22日目の記事です。

先日、 GNS3で所属プロジェクト向けにネットワーク技術のトレーニングメニューを作ってみた(導入編)の日本語版と英語版をMediumに書き、またまた一安心して時間が空いてしまいました。 その間に、所属しているプロジェクト用の次のトレーニングメニューを検証/リリースしていました。 今回はその際に苦戦した事を書こうと思います。AWS SAA英語受験したり、コンテナ技術に興味がありますが、実はネットワークがメインなのです。

ここで話すこと

  • 環境
  • 課題内容
  • vlanが作成できない
  • vlan databaseとは
  • vlan database configuration modeの設定方法
  • 今後の目標

ここで話さないこと

  • 案件の実際の構成や機器
  • GNS3のインストール方法などについて
  • GNS3以外の仮想環境について
  • なぜトレーニングメニューを考えたのか(前回記事にて言及済みの為)
  • なぜGNS3なのか(同上)
  • 現状と課題(同上)
  • 準備期間(同上)
  • 行った準備(同上)
  • 課題作成時のポイント(同上)

環境

課題内容(大問名のみ。個別の問題、詳細は割愛)

<レベル1.0>

  • 1.Ciscoルータ - ホスト名の設定
  • 2.各RouterのインターフェースのIPアドレス設定、インターフェースの有効化 / 無効化、実対応への適用
  • 3.ping疎通確認(サイズ/回数/フラグメントなどのオプション設定)
  • 4.インターフェースのdescription設定 / インターフェイスの状態確認
  • 5.各種showコマンド集(ソフトウェア)
  • 6.各種showコマンド集(ハードウェア)
  • 7.Loopbackアドレス作成およびping疎通確認
    f:id:Yoshiki0705:20190924085744p:plain
    レベル1.0イメージ

<レベル1.5>

  • 1.acl設定(IP/Port単位/pingの遮断可否など)
  • 2.FHRP(First Hop Resolution Protocol)設定(VRRP/HSRP)
  • 3.eBGP設定(タイマー設定など)
  • 4.iBGP設定(OSPF/再配送/オプション設定などに)
  • 5.BGPポリシー分析および設定
    f:id:Yoshiki0705:20190924171056p:plain
    レベル1.5イメージ

<レベル2.0>

  • 0.環境構築
  • 1.LAG設定
  • 2.BGP設定
  • 3.VRFの設定
  • 4.経路情報確認
  • 5.各種テーブル/データベース確認
  • 6.経路制御(ルーティング追加[集約アドレス/Prefix-list]/各種ポリシー適用)
    f:id:Yoshiki0705:20191222225540p:plain
    レベル2.0イメージ

    vlanが作成できない

    「あれ、vlanが作成できない」 レベル2.0の検証作業を行なっていた時のことです。 ここから、本件のトラブルシューティングおよび調査が始まりました。

TEST01(config)#vlan 10
         ^                    
% Invalid input detected at '^' marker.

ヘルプで調べてもvlan configurationモードに入れそうにないです。

POI01(config)#vlan ?
  accounting  VLAN accounting configuration

上記のレベル2.0、0.環境構築を行おうとした所でいきなり詰まりました。 一旦後回しにして次の検証に行こうとしましたが、1.LAG設定でvlan、trunk port設定を入れたかったので調べてみる事にしました。

vlan databaseとは

Ciscoのサイトなどを調べた結果、古いバージョンのイメージでは私が実行した「config-vlan モード」ではなく、「vlan database configurationモード」でvlanが作成できる事がわかりました。 これまで様々なconfigurationモードをCisco機器で操作してきましたが、vlan databaseは意識した事がありませんでした。 私が設定しようとしたvlan 10は、標準範囲VLAN(1~1001)およびVLAN1002~1005はvlan databaseに「vlan.dat ファイル」として格納されます。 それでは、vlan database configurationモードで設定していきます。

vlan database configurationモードでの設定方法

設定例:

configure terminal
vlan vlan-id(標準VLAN1~1001で設定)
name vlan-name(任意の番号や名前)
(apply)
exit

上記のapplyコマンドで設定/変更の適用ができますが、exitでvlan databaseモードを抜けるだけで適用されます。

ここからヘルプコマンドなどで確認しながら設定していきます。

TEST01#vlan database
TEST01(vlan)#vlan ?
  <1-1005>  ISL VLAN index

標準VLANの指定可能

TEST01(vlan)#vlan 10
VLAN 10 added:
    Name: VLAN0010

VLAN 10を名前無指定(VLAN0010)で追加

TEST01(vlan)#vlan 10 ?
  are        Maximum number of All Route Explorer hops for this VLAN
  backupcrf  Backup CRF mode of the VLAN
  bridge     Bridging characteristics of the VLAN
  media      Media type of the VLAN
  mtu        VLAN Maximum Transmission Unit
  name       Ascii name of the VLAN
  parent     ID number of the Parent VLAN of FDDI or Token Ring type VLANs
  ring       Ring number of FDDI or Token Ring type VLANs
  said       IEEE 802.10 SAID
  state      Operational state of the VLAN
  ste        Maximum number of Spanning Tree Explorer hops for this VLAN
  stp        Spanning tree characteristics of the VLAN
  tb-vlan1   ID number of the first translational VLAN for this VLAN (or zero
             if none)
  tb-vlan2   ID number of the second translational VLAN for this VLAN (or zero
             if none)
  <cr>

vlanのオプション、nameなどを確認

TEST01(vlan)#vlan 20 name test
VLAN 20 added:
TEST01(vlan)#exit
APPLY completed.
Exiting....
TEST01#

vlan 20をtestと名付けて追加

TEST01#show vlan
% Ambiguous command:  "show vlan"

vlanを確認するコマンドが通らない(バージョンに寄るもの)

TEST01#show vlan?
vlan-switch  vlans

show vlan-switchコマンドが代わりに使える模様

TEST01#show vlan-switch 

VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
1    default                          active    Fa3/0, Fa3/2, Fa3/3, Fa3/4
                                                Fa3/5, Fa3/6, Fa3/7, Fa3/8
                                                Fa3/9, Fa3/10, Fa3/11, Fa3/12
                                                Fa3/13, Fa3/14, Fa3/15
10   VLAN0010                         active    
20   test                             active    
1002 fddi-default                     active    
1003 token-ring-default               active    
1004 fddinet-default                  active    
1005 trnet-default                    active    

VLAN Type  SAID       MTU   Parent RingNo BridgeNo Stp  BrdgMode Trans1 Trans2
---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------
1    enet  100001     1500  -      -      -        -    -        1002   1003
10   enet  100010     1500  -      -      -        -    -        0      0   
20   enet  100020     1500  -      -      -        -    -        0      0   
1002 fddi  101002     1500  -      -      -        -    -        1      1003
1003 tr    101003     1500  1005   0      -        -    srb      1      1002
1004 fdnet 101004     1500  -      -      1        ibm  -        0      0   
1005 trnet 101005     1500  -      -      1        ibm  -        0      0   
TEST01#

他のバージョンのshow vlanで確認できるID、名前、インターフェイスなどの項目が確認できました。

以上、簡単な検証ですが忘れ易く意外なハマりどころなので、備忘録としてブログに残させて頂きます。 以下の今後の目標は以前書いたものとほぼ重複しておりますが、若干更新しました。

今後の目標

マルチベンダー環境での検証

今回は手軽にスタートできる事を優先し、Cisco機器のみの環境設定としましたが、 他のベンダー機器を入れたり、メインにした構成も作ろうと企んでいます。

仮想環境での操作を前提としたシミュレーションメニューの作成

運用チームのシミュレーションではインターフェイスやBGPのshutdownなどの操作が実機ではできないので省略していますが、 仮想環境では問題無く試せるので、そうしたメニューの開発もサクサクできればと思います。

Contributor、Maintainerの育成

私がこうして去年の施策をヒントに定常的なメニュー作成を企画、実行しているわけですが、 これも属人的なものではなく、業務改善活動の一部としていきたいと思っています。

問題を作成する人、検証/査閲を行う人を育成し、業務フローに落とし込めていければと考えています。既にレベル1.5をクリアされた運用メンバーもいるので、先が楽しみです。 今後の業務自動化も視野に入れた、業務改善活動をもう一歩進めていきたいと考えています。 私自身もレベル2.0までの問題作成/検証作業でかなり現場の構成とそれを支える技術の理解が進みました。 今後はサーバーの構築や移行も行なっていきたいので、次のブログはその辺の内容になるかと思います。

では、また。

Bye now!!

Yoshiki Fujiwara

GNS3で所属プロジェクト向けにネットワーク技術のトレーニングメニューを作ってみた(導入編)

GNS3 トレーニング

先日、英語でのAWS合格体験記をMediumに書き、一安心して時間が空いてしまいました。 その間に、タイトルの通りに所属しているプロジェクト用のトレーニングメニューを検証/リリースしていました。 今回はその話を書こうと思います。実は私、AWS受験したり、コンテナ技術に興味がありますが、ネットワークがメインなのです。

ここで話すこと

  • なぜトレーニングメニューを考えたのか
  • なぜGNS3なのか
  • 現状と課題
  • 準備期間
  • 行った準備
  • 課題作成時のポイント
  • 今後の目標

ここで話さないこと

  • 案件の実際の構成や機器
  • GNS3のインストール方法などについて
  • GNS3以外の仮想環境について

なぜトレーニングメニューを考えたのか

理由は主に下記の3つです。

実機での操作には制約があり、自由に使える検証環境を持っていない為

ここでいう実機とは、サービスが乗っている機器の事であり、showコマンドでも機器に負荷を掛け過ぎるコマンドは打てませんし、 ノードやインターフェイスをDown/Upさせる事もサービス影響が出る、もしくは出る可能性がありますので、できません。

同一プロジェクトの運用チームから設計構築チームに7月に異動し、運用チームに明確な技術的ステップアップの道を作りたかった

運用メンバーとして案件で身に付けておきたい対応、対応できる様に求められている事はリスト化されております。 フローも基本的に明確に決まっていて、必要があれば更新しているので、対応を重ねていけばドンドン仕事ができる様になります。 ところが、実対応が発生するかどうかは良くも悪くも「運次第」という所があり、障害を引いていない人はシミュレーションで補う様になっています。 シミュレーションは出題者が障害対応の経験者が出すので、本番以上に厳しい目でチェックを受けられるのは良いのですが、 上記の通り実機操作が障害内容によっては、本番の様にはできません。 本人のやる気とは関係無しに対応経験値に差が出てしまうので、技術の理解を自身で深めていける、差を埋めていける環境を作りたいと考えました。

自身の個人目標の達成/評価制度の一環

自己紹介や前回のAWS合格体験記でも触れましたが、私は元々IT業界をほぼ未経験で現職に就いており、 「一人称では仕事ができない」という状態でプロジェクトに参加しました。一年の間に現場の仕事を覚えて、色々と動いた結果「一人称で仕事ができる」という評価になりました。 次のステップとして、「メンバーの教育ができる事」などが職種を問わず、要件としてあります。分かりやすく達成する為に上記理由と併せて作成を始めました。

＊自社の評価制度に関する事なので正確な文言はあえて使わず曖昧な表現にしてあります

なぜGNS3なのか

理由は主に下記の2つです。

昨年も前任者を中心にGNS3を使ってトレーニングメニューを作成/実施していた事

私は問題を解く側として誰よりも試行錯誤を繰り返しながらネットワーク技術の理解を深めました。 上手くいかない事を含めて、有識者に教わりながら課題を解決していく事が「楽しい」と思いました。

検証に必要なイメージを持っており、追加のリソース購入/構築が不要

複数のベンダー機器のイメージをプロジェクトで持っており、ある程度柔軟に条件の設定ができます。

現状

現状

  • 運用のメンバーは業務経験は様々。私の様に未経験者もいれば、私よりも年上で運用以外の経験も積んできた方もいます。
  • 取り扱う案件や構成は複数あり、全てのシミュレーションを端から端まで行うのは非現実
  • 緊急性、重要度、影響範囲、発生頻度、などから優先順位を付けてシミュレーションを行っている

準備期間

期間 やったこと
2019年7月 構築チームに異動。担当する構成の確認をしつつ、
GNS3のトレーニングメニューへの反映を模索
2019年8月 レベル1(導入編)を作成し、リリース。
レベル2.0(リーダーレベルへの昇格編)の作成開始
2019年9月前半 レベル2.0が作成/検証に時間を要する事、
深堀りできる要素が多い事が判明し、2つ(1.5を追加)に分ける事を決定
2019年9月後半 レベル1.5(ネットワーク構築編)を検証し、リリース。
レベル2.0は10月前半のリリースを目標に

事務的に準備したこと

  • 上長との実施内容/予定の合意
  • 問題の作成、実行環境の構築
  • チームリーダー陣への先行リリース/フィードバック
  • チームメンバーへの事前アナウンス

課題内容(大問名のみ。個別の問題、詳細は割愛)

<レベル1.0>

  • 1.Ciscoルータ - ホスト名の設定
  • 2.各RouterのインターフェースのIPアドレス設定、インターフェースの有効化 / 無効化、実対応への適用
  • 3.ping疎通確認(サイズ/回数/フラグメントなどのオプション設定)
  • 4.インターフェースのdescription設定 / インターフェイスの状態確認
  • 5.各種showコマンド集(ソフトウェア)
  • 6.各種showコマンド集(ハードウェア)
  • 7.Loopbackアドレス作成およびping疎通確認
    f:id:Yoshiki0705:20190924085744p:plain
    レベル1.0イメージ

<レベル1.5>

  • 1.acl設定(IP/Port単位/pingの遮断可否など)
  • 2.FHRP(First Hop Resolution Protocol)設定(VRRP/HSRP)
  • 3.eBGP設定(タイマー設定など)
  • 4.iBGP設定(OSPF/再配送/オプション設定などに)
  • 5.BGPポリシー分析および設定
    f:id:Yoshiki0705:20190924171056p:plain
    レベル1.5イメージ

<レベル2.0>予定

  • 1.LAG設定
  • 2.再配送設定(集約アドレス)
  • 3.経路情報確認
  • 4.各種テーブル確認
  • 5.VRFの設定

課題作成時のポイント

実務で役に立つ事に絞る

「資格でしか使わない」「IT昔話」はそこに興味がある特殊な人しか触れたくないと思うので、 「実際の案件で使っている技術」「2019年現在、汎用的に使える/覚えておきたい技術」にテーマと質問を絞りました。

選択したり、解いたら終わりの問題にしない

問題/課題が解決したログや根拠、背景となる技術への理解を確認する為の質問を投げ掛ける部分を作りました。 各大問の理解ができているか、深堀りして欲しいポイントをフィードバックしています。

強制参加にしない

前提として、昨年も強制参加ではありませんでした。ただし、やる/やらないの意思表明や理由が必要とされていました。 今回は、「レベルアップの条件」とする事で、必要/意思がある人が実施する様に設計しました。 「やらされている感」が出てしまうと、途端に人はやらなくなったり、自分がやらないだけならば良いのですが、 「頑張っている人の足を引っ張る/やる気を奪う」という行為に出る傾向があります。 ここは、特に重要な部分と考えています。今後の運用を注視していきます。

今後の目標

レベル2.0の作成/検証

レベル2.0の問題はまだ深堀りできていない為、問題の要件定義を実施中です。 要件定義ができたら自身で検証を行い、上長のチェックを経てリリースします。

マルチベンダー環境での設問

今回は手軽にスタートできる事を優先し、Cisco機器のみの環境設定としましたが、 他のベンダー機器を入れたり、メインにした構成も作ろうと企んでいます。

仮想環境での操作を前提としたシミュレーションメニューの作成

運用チームのシミュレーションではインターフェイスやBGPのshutdownなどの操作が実機ではできないので省略していますが、 仮想環境では問題無く試せるので、そうしたメニューの開発もサクサクできればと思います。

Contributor、Maintainerの育成

私がこうして去年の施策をヒントに定常的なメニュー作成を企画、実行しているわけですが、 これも属人的なものではなく、業務改善活動の一部としていきたいと思っています。

問題を作成する人、検証/査閲を行う人を育成し、業務フローに落とし込めればと考えています。 今後の業務自動化も視野に入れた、業務改善活動をもう一歩進めていきたい。

問題の詳細もニーズがあれば公開できるものだと思いますが、別途確認/調整が必要だと考えましたので、 今回は控えさせて頂きました。

では、また。

Bye now!!

Yoshiki Fujiwara

ネットワークエンジニアがAWS Solution Architect Associateを英語で合格した話

AWS AWSSAA English

7月にAWSのCertified Solutions Architect Associate (SAA)を英語で受験し、何とか合格しました。 3度に渡る敗北(不合格)を喫し、「英語じゃなくて日本で受けちゃおうか」という葛藤を繰り返しながらも英語でやり切った記録を残したい、また「どんな形でも誰かの役に立てば」という思いでお届けします。

ここで話すこと

  • なぜ受験したのか
  • 勉強開始前の状態
  • 勉強期間
  • 合格までに行った勉強
  • 試験のポイント
  • 今後の目標

    ここで話さないこと

  • 試験の問題そのものや傾向など(守秘義務と更新が速い為)
  • AWS SAA試験の概要や価値について
  • 英語受験と日本語受験の難易度の違い(日本語受験していないのでわからない為)

  • 寝不足/体調・精神不安定の時の勉強方法(寝れる時に寝て下さい)

    なぜ受験したのか

    おそらく読者の方々の中には、「そもそもネットワークエンジニアがなぜAWSの試験を受験する事になったのか」と疑問に思われる方もいらっしゃると思います。 私自身、初対面の方に説明出来る様に言語化していませんでしたので、改めてこの機会に経緯を下記にまとめました。

  • 30代に入って異業種からエンジニアにキャリアチェンジをしており、自身の価値/成長に不安があり、指標となるスキル/資格を身に付けていきたい

  • クラウド、コンテナ、Cloud Nativeな技術に興味があり、CCNA、LPICレベル1・2の学習がひと段落したので次のステップとして
  • 社内の英語プログラム受講条件が「英語と技術力の両方を磨き、英語で資格を取得すること」となっており、「AWS SAA合格」をコミットして今年から参加している事

勉強開始前の状態

  • 文系卒半熟ネットワークエンジニア(職歴:約1年半)
  • 自己紹介で軽く触れた「物理コンテナの営業」以外にも「レンタカーのコールセンターでバイリンガルチームオペレーター/チームリーダー」など異業種で10年近くの職歴を経ており、業界経験は浅い
  • 普段の業務はお客様先に常駐してISPネットワークの設計/構築
  • AWSを業務で扱った経験は無し
  • AWSのアカウントは個人で持っており、時折触っていた
  • 英語の読み書きはビジネスレベル

    勉強期間(約7ヵ月)

  • 2019年1月～7月 社内の英語プログラムにて英語対策本を読み合わせ/問題演習/不明点の確認
  • 2019年4月～7月 問題演習と受験

結果

  • 4/25(木) 695/1000点 FAIL…
  • 5/30(木) 612/1000点 FAIL…
  • 6/23(日) 664/1000点 FAIL…
  • 7/14(日) 820/1000点 PASS!!

合格までに行った勉強

試験対策本を読む

AWS試験とサービスの概要の理解に利用しました。「これ一冊読んで終わり」ではなく、勉強の取っ掛かりとして良い本だと思います。 ストレージ周りは既に更新されている部分があるので、公式の最新情報の確認をオススメします。

解説が非常に丁寧で、試験で問われない詳細な部分も充実していて、AWSのサービス理解が深まりました。 特に第10章 開発者ツール（Code周りのサービス）、第11章 プロビジョニングサービス(CloudFormation)は他の参考書ではあまり触れていないケースがあり、とても参考になりました。

実機操作

講師がイギリス英語でテンポよく解説をしてくれています。ハンズオンの解説を動画を見ながら自身のアカウントで操作をしていくと、設定の仕方や注意点がイメージ出来て良いと思います。 差分が出る場合もありますので、それが更新によるものか、環境によるものか調べておくと最新の情報や挙動を自分の目で確認出来ます。このコースには模試も付いています。

  • 問題演習後に不明点をハンズオン わからなかった問題や理解が不足していた部分を解説などを確認後に実機操作する事により、自信を持って選択出来る様になりました。

問題演習

合格する為にこれを徹底的に行いました。最初に受験したタイミングでは50%前後しか正解が出来ない状態でしたが、 全6回の試験を3周し、「どんなに調子悪くても8割以上取れる状態」になって試験を受けたら合格しました。

社内の英語プログラムにて英語対策本を読み合わせ/問題演習/不明点の確認

ただ資格を取るのではなく、内容を日英両方で説明/プレゼン出来る様にする事を目指して英語の先生にレッスンをして頂きました。

…ちなみに英語の先生も同じくAWSに挑戦中です。 彼は「教える為には内容を理解していなければならない」とネットワーク、サーバー、プログラミングなどの勉強をしていて生徒(エンジニア)の見本となっています。

  • 上記の問題演習で出てきた不明点の解消

Udemyの問題演習や解説と実機操作に差分があって、調べてもニュアンスが分からない場合、表現の仕方が分からない場合にネイティブチェックをしてもらいました。

月1の社内勉強会とのコラボAWS勉強会

月1回土曜日に有志で本社に集まって実施している勉強会(自己啓発DAY)のスペースを利用して、 AWS有識者(Solution Architect Professional保有者および社内アカデミー講師)による勉強会を開催して頂きました。 有識者のアドバイスはとても詳細かつ網羅的で、求めている理解度が「試験にただ合格するレベル」ではなく実務を行う前提のやり取りだったので、今も参考にさせて頂いています。

社内の英語プログラムでのワークショップ、英語クラブ活動での知見の共有

  • 合格/不合格報告と合格祝いの場

社内では2018年に数名、既に英語でこの試験に合格している方がいましたが、今年新たに1名私の前に合格した方がいました。 私は残念ながら不合格の報告をその前の回で行ったのですが、彼が合格する為に行った事は私と大きく変わらず、 問題演習の理解度が高い事がわかりました。

あれこれ手を出すのはやめて、上記の通りに徹底的に問題演習を行う様にしました。 合格後、英語メンバーで合格祝いのパーティーをしたのは特別な思い出です。先に合格された方の回も私の回も。 次が待ち遠しいです。

試験のポイント

  • 要件にあったものを選択出来る様にする

この試験では「アーキテクトとしての視点」を問われますので、根拠を持って選択肢の中でベストを選ぶ必要があります。 不正解とされる選択肢も「ベストではないだけ」の場合があります。 私の様に、「コスト/セキュリティー/パフォーマンスなどの観点からサービスや構成を組んだ経験が無い」場合は、 サービスの特性や組み合わせを考慮しながら学習や問題演習を進めると良いと思います。私はこの系統の問題が苦手でした。

  • 心身の状態を整えておく

試験問題はそれなりの数(65問程度)あり、試験時間は130分設けられています。 試験前後はなるべく予定を空け、万全な状態で受ける事をオススメします。

緊張/疲れ/焦りなどによる判断ミスや遅れが出る事があります。 私は模試では60分程度で常に試験を完了していましたが、試験の本番では120分以上使っていました。 問題の難易度や環境も多少影響したかもしれませんが、周りの受験者でも同じ症状の方がいたので記しておきます。

私の場合は以下が主な要因でした。

  • 4~6月は夜勤ありのシフト勤務であり、自身の状態を考慮していないスケジュールを組んでしまっていた
  • 7月に運用メンバーから設計構築メンバーへの異動を控えていた為、ネットワーク技術や案件固有の情報を習得が急務だった
  • 翻訳活動や社内外の勉強会参加などに、他にやりたい事に時間を割いていた

試験場に心配事や不安要素を持ち込まない様に準備する事が大切です。

  • 点数を上げる/理解度を深める為の問題演習方法例

    • 1.Udemyなどの模試をやる
    • 2.答え合わせをする
    • 3.Udemyなどの解説、リンクされている資料、AWS公式ドキュメントや解説動画を確認する
    • 4.疑問や不安があったら実機操作で検証 / 有識者に確認する
      この手順を繰り返した事で合格出来ました

  • 最新情報の確認

AWS クラウドサービス活用資料集 など公式資料の最新アップデートは全て目を通しておいた方が良いでしょう。 2019年時点でコンテナ、サーバーレス、自動化はよく聞くテーマですが、新しいサービスや便利になった機能などは試験に出るでしょうし、覚えておいて損は無いと思います。

まとめ

ここまで「公式資料をチェックする」「問題演習や実機操作を通して理解を深める」「心身の状態を整える」など、 考えてみればごくごく当たり前の内容だったと思います。

試験時期、個別の状況やキャラクターに合わせて必要な情報、アドバイスも変わってくると思いますので、 この場では汎用的な内容に留めさせて頂きました。内容に不明な点や個別に確認したい点があれば遠慮なくお声がけ下さい。

私は主に社内で巻き込める方を可能な限り巻き込みながら、何とか合格しました。 「巻き込んだら必ず巻き込まれる」と思っていますので、自発的に恩返しや恩送りをしていきたいと考えています。

今後の目標

  • 資格取得としては以下を狙っています
  • KCM100(Kubernetes and Docker Certification by Mirantis)
  • CKA(Certified Kubernetes Administrator)
  • GCP Associate Cloud Engineer / GCP Professional Network Engineer

Cloud Nativeな技術などに興味があるので学習を進めつつ、実務者としては現在ネットワークエンジニアなので、ルーティングプロトコルはかなり奥が深いのでどっぷり浸かりつつ、 クラウドも含めた構成を考えたり、組んでみたりして技術を深めていきたいです。

  • ブログなどのアウトプットを習慣化する このブログを始め、自身の英語でのプレゼンや日英翻訳などの活動を恒常的に行ってたいと考えています。 先週はブログ書き始めて次の日に、英語のプレゼンがグダグダで切腹したくなったり、他にも諸々あって イベントが走り過ぎな一週間でした。今週も何かそうなりそうな気がしていますが強く生きていきます。

最後に

AWS SAAの合格体験記はそれなりにあると思うのですが、 「英語受験」「ネットワークエンジニア」というキーワードをあまり見かけなかったので、 この記事が似た境遇でチャレンジをされる方、境遇は違えどチャレンジされる方の一助になれば幸いです。 また「運び屋として」少しでも届けられるチャンネルを増やすべく、この記事を英語にしたものをMediumで追って出します。出来れば一週間以内に～。お楽しみに。

では、また。

Bye now!!

Yoshiki Fujiwara

「運び屋」ブログ始めました

自己紹介

はじめまして、Yoshiki0705 と申します。 インフラエンジニアをしています。

この「*運び屋」というブログ名で技術ネタを中心に書いていく予定です。 

特にインフラ、ネットワーク、Cloud Nativeな技術に興味があります。

よろしくお願いいたします。

 

さて、今回は自己紹介を兼ねて「なぜブログを書くのか？」について書いていきます。

 

ブログを書く事になった主なきっかけ3つ：

①勉強会/meetupへの参加

私はIT業界未経験で前職でヘルプデスクを経験後、現職に就きました。

エンジニアとしてのスキルや知識を身に付ける為、社内外の興味あるテーマの勉強会やmeetupに積極的に参加してきました。

その中で「コミュニティーから受け取ってばかりで申し訳ないな」「少しでも貢献したいな」という想いがあり、Japan Cotainer Days V18.12、Cloud Native Days Tokyo 2019のボランティアスタッフ参加、社内勉強会の運営などを行ってきました。

 

そして、情報発信や交流を支えるのも大事で続けていくけれども、「自身で躓いた事や検証/発見した事を発信していきたい」、「トレーニングを受けるだけでなく、サポートしたり、作っていきたい」、「もうちょっと違う形でも貢献したい」という想いを持つようになりました。

 

②プロジェクト内の役割変更

2018年1月から2019年6月までお客様先に常駐するプロジェクトで運用メンバーとして働いていましたが、7月から同一プロジェクトの設計/構築メンバーに異動しました。

役割の変更に伴い、自身の技術習得はもちろん、運用メンバーへの業務説明/教育を行う立場になりました。

早速、仮想環境(GNS3)を利用したネットワーク技術のプロジェクトメンバーへの教育メニューを考え、第一弾をリリースしました。

これから、第二弾、第三弾と続きますが、プロジェクト内の成果や取り組みを「社外にも発表する場を作りたい」と思う様になりました。

 

③社内のエンジニアリングメンタープログラムに参加した事

これが直接のきっかけです。弊社のよこちがnoteで「エンジニアリングメンター」の内容や構想について書いているのでここで詳細には触れません。

一言で言うと「所属している部署に関係なく社内の一歩踏み出そうとしているエンジニアの成長をサポートする相談役」となる*プログラムです。

テーマは主に以下3つで構成されており、私は技術との向き合い方(アウトプット)を選択しました。

・技術との向き合い方(学習方法/アウトプット/職種紹介)

・社外との向き合い方(コミュニティ/勉強会: 参加してみたいけどどう探せばよいか)

・その他(エンジニアに聞いてほしいこと、話したいことなど)

このプログラムでは自律性が重視されており、期間/課題/卒業条件はメンティー側で決めます。

私は上記の様にアウトプットの場を課題としていて、アウトプットの方法/中身/質などについて相談しています。第一回目の打ち合わせでアウトプットの形として、「ブログを書こう」という意見で一致し、様々な提案や情報をもらいました。

「どこでもやっていけるエンジニア」になる事をこのプログラムの目標としており、私が持っている目標と合致しているので、心強い相談役を得て目標を達成していきたいと思います。

 

次のブログは「AWSのSolution Architect Associateを英語で取得した話」を書きます。

経緯や勉強方法について、まとまり次第リリースします。

英語のブログも書こうと考えていますが、ここにするか別の媒体を使うか検討中です。

また、それも決まったら発表していきますので、お楽しみに！

 

では、また。

 

Bye now!!

Yoshiki Fujiwara

 

*ブログタイトルの「運び屋」は私が新卒で勤めた会社で、「物理コンテナーの営業」を行っていた事に由来しています。当時は船会社や航空会社のスペースを使わせて頂いて、世界中の代理店と荷物の世界旅行を手配しておりました。

結局、荷物の輸出入を手配する「通関士」の資格は取りませんでしたが、なぜか英語で人を案内する「通訳案内士(ガイド)」は取りました。

 

*2019/08/26現在、メンターは発案者のよこち1名