クラウド的なアレ

昨日の続き。 IAM IAMを考えるためには、どんなステークホルダーがいてそれぞれどんな責務で、どんなユースケースを持っているか、を情報として整理する。 それによって、どこまでを管理者の権限で許し、どこからは開発者（ユーザー）の自由とするかを決定し、誰の担当かが不明確な作業を減らしていく。 Black Beltの内容を見ていると、アーキテクティングそのものだなと思う。 ちなみに、IAMはそのサービスの性質上、権限の話を中心にすることになるので、ホワイトリスト方式・ブラックリスト方式、どちらでいくのか、というあたりは慎重に判断をしないといけないのだけれど、どちらにせよ「必要最小限」を最初から与えることは難しいので進めながら調整するしかない、という記載があって、現実的で好感が持てた。 AWS Black Belt Online Seminar AWSサービスの権限管理  https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online-seminar-aws IAMのベストプラクティスについては、4つの観点から整理できるみたい。 IDと認証情報の管理 ルートユーザーのアクセスキーを使わない（ルートじゃないとできないのは課金情報へのアクセス権設定、サポートプランの変更、脆弱性診断フォーム提出、逆引きDNS申請、CloudFrontキーペアの作成、解約あたりだけ） パスワードポリシーを強力にする アクセスキーを共有しない 強い権限を持つユーザーはMFAを有効にする アクセス権限の管理 AWS管理ポリシーを適用する（詳細な知識がないと難しいらしい？） 個別のユーザー（IAMエンティティ）へのアクセス権設定をする（インラインポリシー設定する）のではなく、グループへの設定をする（カスタマー管理ポリシー設定する） 権限の委任 EC2上で実行するアプリへはIAMロールを使って権限を与えればセッションとして一定のタイミングで認証が切れるので安全性が高く、その上、AWS SDKを使用することで認証情報の取得や期限切れに伴う再取得を自動実行できる IAMロールを一時的に昇格させるようなことができ、開発用のアカウントが本番用のアカウントの権限のロールを一時的に取得して本番環境のS3にアクセス、といった使い方ができる

仕事で久しぶりに本格的にAWSを使うことになるので、Black Belt等々の資料を見て知識を蓄え直す。 情報の取得元は基本的にここの記事に。 * AWS クラウドサービス活用資料集 Top  https://aws.amazon.com/jp/aws-jp-introduction/ * サービス別資料 | AWS クラウドサービス活用資料集  https://aws.amazon.com/jp/aws-jp-introduction/aws-jp-webinar-service-cut/ CDK CDK = Cloud Development Kit。 CDKの意義は、 * 始めるのが簡単で * 繰り返し可能で * 抽象化可能 ということで、ソースコードからCloudFormationテンプレートが作れる。 手動操作、スクリプト（SDK, CLI）、プロビジョニングツール（CloudFormationやTerraformなど）、Document Object Models（CloudFormationなどのテンプレートを生成）、そして、CDK、という順に管理レベルがMatureになっているイメージ。 AWSのベストプラクティスが定義されたライブラリを使えるので少ないコードで記述ができる。 TypeScript, Python, Java, .NETが対応している。 CDKの内部ではAWS CLIを使用している。 また、CDKがデプロイのためにS3バケットも使用するのでリージョンごとにbootstrapと称した処理を呼びS3バケットを作成する必要がある。 CDKのコアコンセプトは次の6つ * App：CloudFormationテンプレートの生成に使う最上位要素, 複数のStackとその依存関係を定義 * Stack：CloudFormation Stackに該当するデプロイ最小単位でリージョンとアカウント情報を保持する * Construct：AWSリソースコンポーネント、CloudFormationがリソースを作成するのに必要な情報全てをカプセル化してるらしい * Environment：デプロイ先となるアカウントとリージョンの組み合わせ * Context：各種パラメーターのKey-Value、JSONファイルで保存 * SSM ParameterStore

Google AnalyticsやSearch Consoleを眺めているのが面白くて、ブログにも一応導入している。 検索されたワードを見て、同じ内容で自分で検索したところ、確かに検索結果は出てくるものの、下記ページのリンクをクリックするとブログのトップに飛んでしまう。 opendrive github tkhm - Google Search  https://www.google.com/search?q=opendrive+github+tkhm これはなにかがおかしいなということで、とりあえずSearch Consoleに登録している情報に不足があるのではないかと推測してる。 いくつか検索をした結果、サイトマップとしてXML Sitemapとフィードの2種類を登録すれば良いことがわかった。 sitemap.xmlだけだと更新される頻度？クロールされる頻度？が低くて少しリアルタイム性に欠けるので、feedの方も登録した方が良いみたい。 ということで、次のとおり、XML Sitemapとフィード（AtomとRSSの2種）を登録してみた。Bloggerを使っている場合は次の3つを指定すれば良さそう。 /sitemap.xml /feeds/posts/ default /feeds/posts/ default ?alt=rss 絶大な露出を期待しているわけではないけれど、検索結果に出てきたページに飛んでも該当の記事が見れない、というのは悲惨なのでとりあえずその点だけはこれで解決してほしいと思っている。 2014年と少し古い情報だけど、これを参考にした。 XMLサイトマップとRSSフィードの両方を送信することをGoogleが公式に推奨 | 海外SEO情報ブログ  https://www.suzukikenichi.com/blog/google-officially-recommends-to-submit-both-sitemaps-and-feeds/

業務でGraphQLを使用することになったので、なんとなく知っていることもあったけど改めて学習するということで本を読み出してる。 問い合わせ先 操作 データ格納先 SQL クエリ言語によって指定 SELECT, INSERT, UPDATE, DELETE DB 内のテーブル REST エンドポイントによって指定 GET, POST, PUT, DELETE 様々な場所 GraphQL 単一のエンドポイントを使用 Query, Mutation, Subscription 様々な場所 GraphQLではSubscriptionというソケット通信を使った変更監視の機能もあるが、これはSQLやRESTにはない。 GraphQLでの便利ツール * GraphiQL GitHub - graphql/graphiql: GraphiQL & the GraphQL LSP Reference Ecosystem for building browser & IDE tools.  https://github.com/graphql/graphiql * GraphQL Playground GitHub - prisma-labs/graphql-playground: 🎮 GraphQL IDE for better development workflows (GraphQL Subscriptions, interactive docs & collaboration)  https://github.com/prisma-labs/graphql-playground * その他 SWAPI（スターウォーズAPI）、GitHub API、Yelpなどを試すと良い とりあえず、お試し用として紹介されていた次のページでちらちらと遊んでみてる。 Playground -  http://snowtooth.moonhighway.com/

前回からわかったことがある。 今回のJenkins環境は、インフラチームにManageしてもらっている環境なのだけど、JenkinsのRestartとReloadがあり、 Jenkinsで、"Install plugin and restart jenkins after no running job?" と出てOKとすると、Running jobがなければ数秒後にリスタートしているっぽい画面になる。 が、これが今回の一つのはまりどころで、これではJenkinsの設定がReloadされはするものの、Jenkins自体はRestartされないらしい。 このあたりが、Restartというのが何を指しているのかわからない。（プロセスの再起動がRestartなのだろうか、だとしたらReloadはなんらかの内部的なRefresh的な？） ただ、前回必要な項目が出てこないのは単にPluginが適用されてなかったからだった模様。 そもそもtriggersは設定しなくて良くて、といった内容を含んだSeed Job（Jobを作るためのJob）を実行すれば、実際のPipelineのステップ（Jenkinsfile）ではその辺りを気にしなくて良いみたいね。 branchSources { github { buildOriginBranch( true ) buildOriginPRHead( true ) includes( '*' ) excludes( '' ) } } ようやくわかってきたけれど、JenkinsのConfiguration as Code（CasC）としては、 Jenkins自体の設定（jenkins.yaml）とそのJenkins上で動かすJob（xxxx.groovy）とそのJobの中で動くPipeline（Jenkinsfile）があって、Jenkins上で動かすJobをCasCとして保持したい場合はなんらかgroovyファイルとして書いて、次のような形で持っておけば良さそう。 ちなみにMulti Branch PipelineのときはPipelineのファイル名はJenkinsfileで固定が基本みたい。（ちょっと検索した感じ、変えられるけどしんどそうだった） api_uri

OpenShiftでいくつか検証をしている中で、永続ストレージを使用する必要が出てきた。 地味に初挑戦で戸惑う点もあったのでメモ。 TL;DR クラウドのManagedの環境でPersistent Volume Claim（以下、PVC）を作ると、Persistent Volume（以下、PV）が作られ、そのPVに紐づくストレージがIBM Cloud上に払い出される、というところまでが自動的に実施される どのストレージが払い出されるかは選んだStorage Classに依存する, IBM CloudだとProvisionerが “ibm.io/ibmc-file” だったらファイルストレージ、”ibm.io/ibmc-block”(註：大事なところを誤って-fileと書いていましたので訂正しました......)  だったらブロックストレージ 払い出されたストレージのマウントパスを見てPVを同様に作り、そのPVを参照するPVCを作れば同じストレージのマウントパスを参照させることが可能になる 同僚（と言ってもOpenShiftの文脈では大先輩）と話し、PVはClusterのストレージとの紐付きのI/FでPVCはPVとNamespaceとの紐付きのI/Fだと聞いた。 以下で誤った素人理解をいくつか記載する。 誤り1：複数Deploymentでも同じNamespaceなら同じPVCを使いまわせる こうすればできる：Deployment（Pods）の中でsubPathを使う volumeMounts: - mountPath: /var/ www/html name: site-data subPath: html 出典：Volumes | Kubernetes  https://kubernetes.io/docs/concepts/storage/volumes/#using-subpath この方法は軽量で望ましいと経験のある同僚は言っていた。 ただ、出典見る限り、同じPod内で複数使う場合だから複数のDeploymentで使えるのかは検討する必要がある気がした。 が、同僚が実績ありとのことなので取りうる方法なのだと思う。 誤り2：複数のPVCで同じPVを参照できる こうすればできる：あるPVが指しているマウント先と同じマ

Windows Server 2019をクラウド上で使っていて、突然リモートデスクトップが接続できなくなることが3連続で発生した。 1, 2度目は急いでいたこともあり、サポートからの回答を待たずにOS Reloadにて対応した。メインのディスクをリロード時に保持しておくオプションを使えば、リロード後もインストール済みのミドルウェアなどは問題なく動いていた。 とはいえ、あまりに現象としては気持ち悪いのでサポートへの問い合わせは2度目, 3度目でそれぞれ実施した。 結論としては、XenToolsの自動更新時にIP Addressがなくなってしまう事象が既にKnown Issueとして上がっているらしく、その自動更新を止めるのが最善手として案内されている。 2度目のときには日本のサポートの方が対応してくれたみたいで、次のQiitaの記事を紹介してもらった。また、そのサポートの方曰く、Windows Server 2019のPublicのNetwork I/Fを有効にしている場合に起きる、とのこと。 XenToolsの自動更新を停止する方法  https://qiita.com/testnin2/items/79af53cfd8e3d1ce2ae2 3度目のときは別の方だったけれど、やはりQiitaの記事内にあるものと同様の内容を紹介してもらった。 Disabling the Management Agent Updates  https://support.citrix.com/article/CTX222494 要するに、Admin権限で次のコマンドを実行してね、ということらしい。 reg ADD HKLM\SOFTWARE\Citrix\XenTools /t REG_DWORD /v DisableAutoUpdate /d 1 Value DisableAutoUpdate exists, overwrite(Yes/No)? Yes The operation completed successfully. その後、次のコマンドで実施結果が反映されているか確認できる。 reg query HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\XenTools Qiitaの方だともう少し丁寧で、スケジューラーの方の話にも触れてくれている。 下記で無

IBM Cloudではセキュリティグループ（簡易FW）があるので、セットアップをした。 ところが、いつまで経ってもnmapでのスキャンができるしRDPのポートを閉じたはずなのにつながってしまう。 いくつかの試行錯誤とドキュメントの読み込みから分かったのは、一度以上、Inbound, Outbound「それぞれ」で何かしらの設定をしないと効かないということ。 公式ドキュメントには、一度セキュリティグループを適用するとそれ以降有効になって、明示的にAllowしたもの以外通らない、って書いてあるのにその通り動かなくて困ってしまっていた。 OutboundはすべてOK、Inboundは一切不可、を設定するため、Outbound側にはAllowの設定を入れた。 想定ではこれによりセキュリティグループが有効になりInboundはAllowを何もしていないからすべてDenyになると思っていた。 が、実態としては、Outboundにだけルールを設定していて、Inboundになにも許可の設定を一度もしていないと、Outboundのセキュリティグループは有効になるが、Inboundのセキュリティグループは有効にはならない模様。 インスタンスのネットワークインタフェーズのIn/Outそれぞれで別で管理されているのね。（＝適用すると有効になる、のは各インタフェースのIn、Outそれぞれにかかっていたということか……） なので、一度任意のポートなりなんなりのInboundがAllowになるような設定を入れてからそれを消せば、期待通り全てのInboundがブロックされるようになる。 大した話じゃないけど地味に手強かった。 About IBM Security Groups  https://cloud.ibm.com/docs/security-groups?topic=security-groups-about-ibm-security-groups#about-ibm-security-groups

少し間が空いた。 まず最初は、名前付けの話として、Arlo Belsheeの記事であるNaming as a Processに言及している。（書籍の中ではこの記事の前身の記事で、Good Namign Is a Process, Not a Single Stepという記事だったみたい） Deep Roots - Naming as a Process (Article 1)  https://www.digdeeproots.com/articles/naming-as-a-process/ 私たちが選ぶ名前は、設計しているものをどれほどよく理解しているかを反映している。理解が深まるにつれ、概念に付ける名前も変わる。Belsheeの「名前付けの7段階」をソフトウェアアーキテクチャに適用したものを次に示す。 ステージ1：名無し - 名前がない状態。システムやコンテキストについて、名前付き要素を抽出するのに十分なだけのことが分かっていない。 ステージ2：無意味 - 名前に意味はないものの、何らかの形で関連していると考えられるアイデアの集まりを特定した状態。 ステージ3：的確 - 要素の責務について少なくとも1つを表している状態。 ステージ4：的確かつ完全 - 要素のすべての責務を直接表している状態。 ステージ5：適切な行い - 要素の責務を進化させるという意識的な決定が名前に反映されている状態。これは、アーキテクチャの文脈における要素の役割について、より多くの知識が得られたときにのみ起こる。 ステージ6：意図 - 名前には要素の責務だけではなく目的も表されている。目的を理解するには、その要素に加えて、その要素の存在理由を理解する必要がある。 ステージ7：ドメイン抽象 - 名前は個々の要素を超えて新しい抽象概念を作成する。これがメタモデルのための新しい概念が生まれるところだ。 良い名前をつけることは重要だというのは一定の経験のあるシステムエンジニアの中では自明だと思っているけれど、それをステージ別に整理しているのがわかりやすいと思った。 それから、これは自分が会社の研修で習ったことのある話と全く同じだった。 プログラミングデザインパターンとアーキテクチャデザインパターンを区別することはそれほど重要ではない。結局のところ、ある人のアーキテクチャは別の人の詳細な設計かもしれ