  |
はてなキーワード:環境変数とは
【はじめに】
法的には、彼は解散権という核ボタンを持ち、人事権という生殺与奪の剣を握る「全能の王」に見える。
しかし、構造的に見れば、彼は巨大な官僚機構、党内力学、そして対米従属という三重の鉄壁に囲まれた「独房の囚人」に過ぎない。
本シリーズの最終章となる本稿では、この「システム（構造）」と「アクター（個人）」の間に横たわる、残酷な力学を解剖する。
なぜ、改革を叫ぶ者は短命に終わり、何もしない者が長期政権を築くのか？
ここにあるのは、個人の資質の問題ではない。システムが許容する「自由意志」の総量が、最初から決まっているという物理法則である。
「操縦桿」は繋がっているか？
日本政治という巨大な飛行機（リヴァイアサン）において、コックピットに座る首相が握る操縦桿は、実は主翼（政策実行機能）と繋がっていないことが多い。
この操縦桿は、フライ・バイ・ワイヤ（電気信号）で制御されているが、その信号を処理するコンピューター（官僚・米国・派閥）が、入力された命令を「解釈」し、勝手に書き換えるからだ。
日本の首相官邸というコックピットにおいて、パイロットが選択できる行動パターンは数学的に以下の三つしかない。
衝突：システムと正面衝突し、破砕する。
それぞれの運命を、具体的な検体（歴代首相）を通じて検証する。
岸田文雄（2021-2024）は、無能だったから短命だったのではない。逆に、このシステムにおける「理想的な統治者」としての適性が高すぎたために、存在自体が空気（環境変数）と同化した稀有な例である。
官僚機構、派閥の長老、連合、そして米国。あらゆるステークホルダーからの入力信号（Input）を、一切のフィルタ（個人の自我）を通さずに、そのまま政策として出力（Output）する機能のことだ。
財務省が増税を囁けば「増税」と出力し、世論が反発すれば即座に「減税」と出力する。ここには「変節」という概念さえ存在しない。ただ「入力が変わったから出力が変わった」という、機械的な反応があるだけだ。
官僚にとって、これほど扱いやすいUI（ユーザーインターフェース）はない。
彼が多用した「検討を加速させる」という再帰的なループ言語は、決定責任を回避しつつ時間を稼ぐ、このシステムが産んだ最高の防御呪文であった。
彼は「何も成し遂げなかった」のではない。「何もしないことで、システムを安定させた」という点で、最も純粋なシステムの部品であった。
【Type B】異端：鳩山由紀夫・田中角栄という「免疫拒絶」
システムは「自律的な意志」を持つ部品を、ウイルスとして検知する。
田中角栄（ロッキード事件）と鳩山由紀夫（普天間移設）は、左右の違いこそあれ、システム（特に第2層の官僚と第3層の米国）の回路を、個人の意志で書き換えようとした点で共通している。
破壊工作の失敗：
田中角栄： 彼は「カネ」という潤滑油を大量に注ぎ込むことで、官僚機構（法による支配）を無力化し、日中国交正常化などの独自外交（対米自立の萌芽）を行った。
鳩山由紀夫： 彼は「友愛」というイデオロギーで、日米安保というOSの根幹（抑止力論理）を無効化しようとした。「最低でも県外」という言葉は、システムへの宣戦布告であった。
リヴァイアサンは、彼らを政治的に殺すために「免疫細胞」を動員した。
田中には「東京地検特捜部」という司法の牙が、鳩山には「外務省官僚によるサボタージュと極秘文書のリーク」という行政の罠が襲いかかった。
「構造に逆らった個人の意志は、必ず物理的に排除される」という、システムの自己防衛機能が正常に作動した結果である。
彼らの屍は、後続の政治家たちへ強烈なメッセージを残した。「操縦桿を勝手に動かすな」。
【Type C】ハッカー（Hacker）：安倍晋三・高市早苗という「悪魔的取引」
彼らは、システムと戦う愚かさ（Type B）も、システムに埋没する虚しさ（Type A）も知っていた。
ゆえに彼らは、システムそのものを「ハッキング」することを選んだ。彼らは構造を変革するのではなく、構造の「脆弱性（Bug）」を突くことで、擬似的な王権を創出した。
安倍晋三（第二次政権）の発明は、官僚と戦うのではなく、官僚の「人事」を握ることで、彼らを「恐怖」で支配下に置いたことだ。
これにより、官僚機構（第2層）は「抵抗勢力」から「忖度する手足」へと変質した。
歴代の首相たち――橋本龍太郎も、小泉純一郎も、民主党の菅直人も――皆、官僚機構（霞が関）と戦い、そして敗北あるいは妥協を余儀なくされた。
なぜ彼らは失敗し、安倍晋三だけが官僚を「忠実な下僕」に変えることができたのか？
2014年に実装された、たった一つの「構造変更パッチ」にある。
以前のシステム：「聖域」だけは触れない
2014年以前、日本の首相は「法律」を作ることはできたが、官僚の「人事」に口を出すことはタブー（聖域）とされていた。
各省庁の事務次官や局長は、省内の序列と互助会的な論理で決定され、首相は最後にハンコを押すだけの「ハンコ」に過ぎなかった。
この構造下では、官僚の忠誠心は「時の総理」ではなく、「所属する省庁」に向けられる。
だからこそ、彼らは平気で面従腹背し、サボタージュを行い、情報をリークして政権を倒すことができた（民主党政権が殺された主因はこれである）。
安倍晋三（と当時の菅義偉官房長官）は、このバグを冷徹に見抜いていた。
2014年、第二次安倍政権は「国家公務員法」を改正し、内閣人事局を新設。
これにより、審議官級以上の幹部公務員（約600人）の人事権を、各省庁から取り上げ、官邸（内閣官房）が一元管理するシステムへと書き換えた。
これは、OSの「管理者権限（RootAccess）」の奪取に等しい。
効果は劇的だった。
かつて「法の番人」を自認していた法務官僚も、財政規律を守っていた財務官僚も、自らの出世と組織防衛のために、官邸の意向を「先回りして推測（忖度）」し、公文書の改ざんすら厭わない「忠実な兵隊」へと変貌した。
小泉純一郎は「郵政」という局地戦には勝ったが、官僚機構そのものは温存した。
民主党は官僚を「敵」として怒鳴りつけたが、人事権という武器を持たずに戦ったため、寝首をかかれた。
安倍晋三だけが、「人事権という首輪をつければ、猛獣もペットになる」という構造力学を理解し、それを制度化したのである。
これが、彼が「憲政史上最長の政権」を築けた最大のトリックであり、同時に日本の官僚制（明治層）の魂を完全に殺した「毒」の正体でもある。
さらに彼は、米国（第3層）に対し、集団的自衛権という「最高の貢物」を差し出すことで、国内政治におけるフリーハンド（黙認）を勝ち取った。
彼女の「保守的な言動」は、イデオロギーではない。あれは、岩盤保守層（第1層の農村・地主の変種）を繋ぎ止め、同時にシステム内部の求心力を維持するための「認証コード」である。
彼女は、安倍政権が残した「ハッキング・ツール（人事権と安保連携）」を継承し、さらに「非常時（台湾有事の危機）」という外部環境を利用して、システムの権限を極限まで集中させている。
代償：
ハッカーたちは強い。しかし、その強さは「システムの一部（公共性や法の支配）」を犠牲にして得たものだ。
彼らが長期政権を維持すればするほど、官僚は萎縮し（公文書改ざん）、財政は規律を失い（異次元緩和）、国は「私物化」されていく。
彼らは操縦しているように見えるが、実際には「機体のパーツを取り外して燃料にくべながら、加速し続けている」に過ぎない。
これは一見、彼女の強烈なリーダーシップ（能動性）に見える。しかし、本シリーズの視座から見れば、それは違う。
彼女もまた、システムが生き残るために選ばれた「機能」に過ぎない。
「改革」という名のエンターテインメントを国民に提供し、ガス抜きをする。そのために、彼女の攻撃的なキャラクター（UI）が採用されただけだ。
彼女が操縦桿を右に切ろうが左に切ろうが、機体は「現状維持」という航路から1ミリもズレない。
なぜなら、エンジン（経済構造）も、管制塔（米国）も、整備士（官僚）も、誰も航路変更など望んでいないからだ。
“善良”な「依代」が統治すれば、国は緩やかに衰退する（死に至る病）。
“勇敢”な「異端」が統治すれば、国は即座にパニックに陥り、彼自身が殺される（拒絶反応）。
“狡猾”な「ハッカー」が統治すれば、国は熱狂の中でその骨格を食い荒らされる（自己中毒）。
なぜなら、コックピット（首相官邸）の設計そのものが、「主権の欠損」を前提に作られているからだ。
我々が目撃しているのは、高度に発達しすぎた官僚制と資本主義の複合体が、もはや人間の「意志」を必要としなくなった光景である。
政治家の「主観的能動性」は、いまやシステムにとって「リスク」でしかない。
したがって、システムは最も「空っぽな人間」か、最も「システムに過剰適応したハッカー」だけをコックピットに招き入れる。
操縦席には誰もいない。あるいは、「誰もいない」のと同じ状態の人間しか座れない。
それでもリヴァイアサンは飛び続ける。燃料（国民の税と魂）が尽きて、墜落するその瞬間まで。
政治が「悪い」ことではない。
「ソースコードに間違いが見つからないのに想定される出力をしない。あるいはソースコードに修正を加えていないのにいきなり想定出力を返すようになった。」
こういう経験がある人はいるはずだ。なぜこれが起こるのか。一つの原因を見つけた。
それは環境変数や設定ファイルに存在する。デプロイ時には設定ファイルを特定の値に修正してから、ということがあるだろう。
開発環境でコーディングする人が、デプロイ時の設定ファイルには関与せず、デプロイの担当者がそれを把握している。
開発者はセキュリティ上の理由でデプロイ時の設定ファイルの内容を見ることができない。
この場合、設定ファイルの内容が間違っていても、開発者が原因が正しく特定できないケースがあるのである。
対処方法は以下である。まず事前にやっているであろう対処は以下である。
追記:
他に遭遇したケースは、環境のアップグレードによってphpが特定の関数を廃止したというケースだ。
なるべく手持ちのPC（以下、ホストPC）の環境をレジストリとか環境変数とかで汚したり悩まないよう
Windows10 ProとWSL2とVSCodeとDockerでやる感じかな
UnityとかVisual StudioとかintellijとかAndroid Studioを使う場合はどうしようもないので諦める。
Android開発はVSCodeでビルドはコマンドラインでとかはできそうだけど。
あとはUSBなどでシリアル接続する必要のあるarduinoとかもちょっと難しいかもしれない
これが基本的なところだけど、WSL2をホストPCに入れるので若干汚れるのとWSL2上のlinuxも同じく汚れるところ
Hyper-VでWindowsの仮想マシンを作ってそのうえでWSL2を動かすのが一番汚れずクリーンに使えそう
ただRyzenとWindows10の組み合わせだと、Hyper-Vの入れ子ができないので仮想マシン上のWSL2は動かないらしい。
Windows11だとできる
手元じゃないのでクリーンに使えるが、ビルドなどはリモートのスペックに依存
そこをよしとすれば楽そう
教えてください。
「猿でも分かるプロンプト活用術」というタイトルでの電子書籍について、以下に簡単な目次と章ごとの概要を示します。実際の書籍を作成するには、これらの各セクションを詳細に説明し、例や図を追加する必要があります。
目次:
1. はじめに
2.コマンドプロンプトとは何か
8. まとめ
9. はじめに
・グラフィカルユーザーインターフェイス(GUI)との違い
・コマンドプロンプトの開き方
・基本的なコマンドの使い方（例：help、cls、exit）
...
はじめに
コンピュータの世界は日々進化し続けており、我々が日常的に使用するデバイスやソフトウェアは常に更新され、より使いやすく、効率的になっています。しかしながら、コンピュータの基本的な操作や理解には、依然として古くから存在するコマンドプロンプトという強力なツールがあります。このツールは、多くのユーザーにとって未知の存在であり、その力を十分に発揮できていないかもしれません。
本書「猿でも分かるプロンプト活用術」は、コマンドプロンプトをこれまで使ったことがない方や、基本的な操作しか知らない方を対象に、この強力なツールを効果的に利用する方法をわかりやすく解説します。また、既にコマンドプロンプトを使用している中級者にも、さらなる活用方法を学んでいただける内容となっています。
コマンドプロンプトは、グラフィカルユーザーインターフェイス（GUI）に慣れ親しんだ現代のユーザーにとっては、最初は少し難しく感じるかもしれません。しかし、本書を通じて、コマンドプロンプトの基本操作から高度な活用法までを習得し、日々の業務やパソコン操作に役立てることができるようになります。
各章では、具体的なコマンドの例やスクリーンショットを用いて、わかりやすく説明を行います。また、章ごとに練習問題やチャレンジを設けていますので、学んだ知識をすぐに実践して確認することができます。
この本を通して、コマンドプロンプトの力を最大限に引き出し、あなたのコンピュータスキルを向上させることができることを願っています。それでは、さっそく「猿でも分かるプロンプト活用術」の世界に飛び込んでみましょう！
ちなみに全くの未経験。
“helloworld”から一歩も進まない、Python死ね。
いやPythonは悪くないんだ。俺みたいなのがやろうとしたのが間違いなのだ。
逆恨みだが死んでくれ。
肉体労働者だからパソコン触るのも数年ぶり、そもそもプログラミングというものは、パソコンの素養がないとあかんのだな。
仕事で必要というわけでは全然なく、別にそっちの道を目指そうという気もない。
チェスが昔から下手な横好きなんだが、変則チェスのゲーム作りたいなと思っただけなんだ。
Pythonを選んだのは、定石なんかに機械学習があると良いのかな、くらいに思ったのと、初心者に優しいとググったら出てきたから。
Pythonのやり方ググると、ダウンロードしろというからダウンロードする。
コマンドプロンプトを起動して、
python-V
と打ち込むわけだ。
「’python’は内部コマンドまたは外部コマンド、操作可能なプログラムまたはバッチファイルとして認識されていません」
？？？？
py -V
だと
って出てくんのが尚更意味わからん。ランチャーとかいうもののおかげらしい、だからなんだよ。
予めどこのファイルにあるかコピペしとけって動画はたくさんあるが、し損ねたやつ向けの話が全然出ない。
検索するとたまにそれに触れた知恵袋的な質問が出てくるが、なぜかことごとくスルーされて回答されない。
隠しファイルなるものの存在も初めて知ったが、で？どこ？という核心がわからない。
一旦Pythonをアンインストールして振り出しに戻してからやろうとしたが
「復帰すんの？ええよ！」と言いたげなrepairなんたらかんたらって表記は出ても、結局どこでどうしたらええか出てこない。
掲示板とかで見てると「ぶちこめば良い」とかは言っても実際それがどんな手順を踏むのかわからん。
開始30分から2週間、全く進展がなくて流石に心が折れた。終わり。
--
この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に１つのプロセスが稼働している扱いになる。
【Dockerとは】
アプリをコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。
イメージ(アプリケーションと依存関係がパッケージングされる。アプリ、ライブラリ、OS)
レジストリに保存
【Dockerfileとは】
このファイルにコマンドを記述することで、アプリに必要なライブラリをインストールしたり、コンテナ上に環境変数を指定したりする。
1章まとめ、感想
コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンドや設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。
2章
ECSとEKSがある。
オーケストレーションサービスであり、コンテナの実行環境ではない。
ECSの月間稼働率は99.99%であることがSLA として保証。
デプロイするコンテナイメージ、タスクとコンテナに割り当てるリソースやIAMロール、CloudWatch Logsの出力先などを指定する。
指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサーやタスクを実行するネットワークを指定。
2種類ありECSとFargateがある。 Fargateに絞って書く
Fargateとは
コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する
サーバーのスケーリング、パッチ適用、保護、管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる
・コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる
ECR
・AppRunner
利用者がコードをアップロードするだけでコードを実行できるサービス。AWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス。
AppRunner
2021年5月にGA(一般公開)となったサービス。プロダクションレベルでスケール可能なwebアプリを素早く展開するためのマネージドサービス。Githubと連携してソースコードをAppRunnerでビルドとデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。
ECSとFargateの場合、ネットワークやロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識は必要になる。AppRunnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である。
ECS Fargateを利用した場合のコスト、拡張性、信頼性、エンジニアリング観点
【コスト】
EC2より料金は割高。ただし、年々料金は下がってきている。
【拡張性】
デプロイの速度 遅め
理由1コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる
理由2.イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。
タスクに割り当てられるエフェメラルストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要な場合はEFSボリュームを使う手もある。
割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリを要求するホストとしては不向き
【信頼性】
Fargateへのsshログインは不可。Fargate上で起動するコンテナにsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境にsshの口を開けるのはリスキーである。他にSSMのセッションマネージャーを用いてログインする方法もあるが、データプレーンがEC2の時に比べると手間がかかる。
しかし、2021年3月にAmazonECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。
Fargateの登場からしばらく経過し、有識者や経験者は増え、確保しやすい。
多数のユーザーに使ってもらう
CI/CDパイプラインを形成し、アプリリリースに対するアジリティを高める
各レイヤで適切なセキュリティ対策（不正アクセス対策、認証データの適切な管理、ログ保存、踏み台経由の内部アクセス）を施したい
2章まとめ、感想
AWSが提供するコンテナサービスにはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理が不要でインフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である。
3章
この章では運用設計、ロギング設計、セキュリティ設計、信頼性設計、パフォーマンス設計、コスト最適化設計について述べている。
Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計、不具合修正やデプロイリスク軽減のためのCI/CD設計が必要である。
モニタリングとは
システム内で定めた状態を確認し続けることであり、その目的はシステムの可用性を維持するために問題発生に気づくこと
オブザーバビリティとは
オブザーバビリティの獲得によって、原因特定や対策の検討が迅速に行えるようになる
・cloudwatch logs
・Firelens
AWS以外のサービスやAWS外のSaaSと連携することも可能
Firehoseを経由してS3やRedshift やOpenSearch Serviceにログを転送できる
fluentbitを利用する場合、AWSが公式に提供しているコンテナイメージを使用できる
-ソフトウェアやライブラリの脆弱性は日々更新されており、作ってから時間が経ったイメージは脆弱性を含んでいる危険がある。
-方法
脆弱性の有無はECRによる脆弱性スキャン、OSSのtrivyによる脆弱性スキャン
継続的かつ自動的にコンテナイメージをスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリの場合、CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャンも必要になる。
cloudwatch Eventsから定期的にLambdaを実行してECRスキャンを行わせる（スキャン自体は1日1回のみ可能）
Fargateの場合、サービス内部のスケジューラが自動でマルチAZ構成を取るため、こちらで何かする必要はない。
・障害時切り離しと復旧
ECSはcloudwatchと組み合わせることでタスク障害やアプリのエラーを検知できるうえに、用意されてるメトリクスをcloudwatchアラームと結びつけて通知を自動化できる
ALBと結びつけることで、障害が発生したタスクを自動で切り離す
AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合、ECSは新しいタスクに置き換えようとするその状態のこと。
Fargateの場合、アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ不整合などが生じて危険。
ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能
自動でクォータは引き上がらない
パフォーマンス設計で求められることは、ビジネスで求められるシステムの需要を満たしつつも、技術領域の進歩や環境の変化に対応可能なアーキテクチャを目指すこと
利用者数やワークロードの特性を見極めつつ、性能目標から必要なリソース量を仮決めする
FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーとターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める
既存のワークロードを模倣したベンチマークや負荷テストを実施してパフォーマンス要件を満たすかどうかを確認する
・スケールアウト
サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存のタスクを停止する必要は原則ない。
スケールアウト時の注意
・Fargate上のECSタスク数の上限はデフォルトでリージョンあたり1000までであること。
ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能なIPアドレスが消費されていく
Application Autoscaling
CloudWatchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う
CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
--
この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に１つのプロセスが稼働している扱いになる。
【Dockerとは】
アプリをコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。
イメージ(アプリケーションと依存関係がパッケージングされる。アプリ、ライブラリ、OS)
レジストリに保存
【Dockerfileとは】
このファイルにコマンドを記述することで、アプリに必要なライブラリをインストールしたり、コンテナ上に環境変数を指定したりする。
1章まとめ、感想
コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンドや設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。
2章
ECSとEKSがある。
オーケストレーションサービスであり、コンテナの実行環境ではない。
ECSの月間稼働率は99.99%であることがSLA として保証。
デプロイするコンテナイメージ、タスクとコンテナに割り当てるリソースやIAMロール、CloudWatch Logsの出力先などを指定する。
指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサーやタスクを実行するネットワークを指定。
2種類ありECSとFargateがある。 Fargateに絞って書く
Fargateとは
コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する
サーバーのスケーリング、パッチ適用、保護、管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる
・コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる
ECR
・AppRunner
利用者がコードをアップロードするだけでコードを実行できるサービス。AWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス。
AppRunner
2021年5月にGA(一般公開)となったサービス。プロダクションレベルでスケール可能なwebアプリを素早く展開するためのマネージドサービス。Githubと連携してソースコードをAppRunnerでビルドとデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。
ECSとFargateの場合、ネットワークやロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識は必要になる。AppRunnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である。
ECS Fargateを利用した場合のコスト、拡張性、信頼性、エンジニアリング観点
【コスト】
EC2より料金は割高。ただし、年々料金は下がってきている。
【拡張性】
デプロイの速度 遅め
理由1コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる
理由2.イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。
タスクに割り当てられるエフェメラルストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要な場合はEFSボリュームを使う手もある。
割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリを要求するホストとしては不向き
【信頼性】
Fargateへのsshログインは不可。Fargate上で起動するコンテナにsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境にsshの口を開けるのはリスキーである。他にSSMのセッションマネージャーを用いてログインする方法もあるが、データプレーンがEC2の時に比べると手間がかかる。
しかし、2021年3月にAmazonECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。
Fargateの登場からしばらく経過し、有識者や経験者は増え、確保しやすい。
多数のユーザーに使ってもらう
CI/CDパイプラインを形成し、アプリリリースに対するアジリティを高める
各レイヤで適切なセキュリティ対策（不正アクセス対策、認証データの適切な管理、ログ保存、踏み台経由の内部アクセス）を施したい
2章まとめ、感想
AWSが提供するコンテナサービスにはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理が不要でインフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である。
3章
この章では運用設計、ロギング設計、セキュリティ設計、信頼性設計、パフォーマンス設計、コスト最適化設計について述べている。
Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計、不具合修正やデプロイリスク軽減のためのCI/CD設計が必要である。
モニタリングとは
システム内で定めた状態を確認し続けることであり、その目的はシステムの可用性を維持するために問題発生に気づくこと
オブザーバビリティとは
オブザーバビリティの獲得によって、原因特定や対策の検討が迅速に行えるようになる
・cloudwatch logs
・Firelens
AWS以外のサービスやAWS外のSaaSと連携することも可能
Firehoseを経由してS3やRedshift やOpenSearch Serviceにログを転送できる
fluentbitを利用する場合、AWSが公式に提供しているコンテナイメージを使用できる
-ソフトウェアやライブラリの脆弱性は日々更新されており、作ってから時間が経ったイメージは脆弱性を含んでいる危険がある。
-方法
脆弱性の有無はECRによる脆弱性スキャン、OSSのtrivyによる脆弱性スキャン
継続的かつ自動的にコンテナイメージをスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリの場合、CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャンも必要になる。
cloudwatch Eventsから定期的にLambdaを実行してECRスキャンを行わせる（スキャン自体は1日1回のみ可能）
Fargateの場合、サービス内部のスケジューラが自動でマルチAZ構成を取るため、こちらで何かする必要はない。
・障害時切り離しと復旧
ECSはcloudwatchと組み合わせることでタスク障害やアプリのエラーを検知できるうえに、用意されてるメトリクスをcloudwatchアラームと結びつけて通知を自動化できる
ALBと結びつけることで、障害が発生したタスクを自動で切り離す
AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合、ECSは新しいタスクに置き換えようとするその状態のこと。
Fargateの場合、アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ不整合などが生じて危険。
ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能
自動でクォータは引き上がらない
パフォーマンス設計で求められることは、ビジネスで求められるシステムの需要を満たしつつも、技術領域の進歩や環境の変化に対応可能なアーキテクチャを目指すこと
利用者数やワークロードの特性を見極めつつ、性能目標から必要なリソース量を仮決めする
FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーとターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める
既存のワークロードを模倣したベンチマークや負荷テストを実施してパフォーマンス要件を満たすかどうかを確認する
・スケールアウト
サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存のタスクを停止する必要は原則ない。
スケールアウト時の注意
・Fargate上のECSタスク数の上限はデフォルトでリージョンあたり1000までであること。
ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能なIPアドレスが消費されていく
Application Autoscaling
CloudWatchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う
CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
都議選に集まる批判、デンベレグリーズマン(海外セレブ)の日本人労働者への差別発言、国民感情を無視したオリンピック開催、天皇のお気持ち発表、鬼滅の刃大ヒット、全ては腐った民主主義が終了して天皇による寡頭政治が始まる布石や。自民の票田になってる国粋主義者達を本気出した天皇が掻っ攫って全部終わらせてくれ。皆がアホやから民主主義が機能せえへんって嘆いてるリベラルの本音も、優秀な人間だけで寡頭政治やって欲しい、やろ。
責任者不在の政治も当事者意識のない選挙もやめてまえ。選挙に絶望しててなるようになったもんを環境変数として受け入れる大衆とそれが出来ひんぐらい窮地に立たされて割りを食ってる一部の国民がこの国の構成員や。前者は誰が環境変数を設定したかに興味がないし、後者はいざとなったときにクーデター起こす相手がハッキリしてたほうがいいやろ。
私が悪かったので責任を取ります言うて一番目立つ席に座ってた人がひとつ下に移動して引き続き甘い汁吸って、組織自体は根本的には何も変わらんって政治をいつまでも続けるより、君主一人 対国民全員の緊張感ある政治にしようや。
45歳多重派遣と言っても、噂のGitHubの人ではない。すまんな。。
皆さんはプロジェクトの共有ディレクトリの最下層に”女子大生”という何もないファイルを作ってアクセスログをとっていたのがバレて怒られた事はあるか？私はある。２回。
仕事でとうとうGitHubすら使わずにプログラマ人生を終えてしまった。
レガシーな技術を使いがちな金融プログラマではそこそこ居るのでは無いだろうか。
年収は20代後半からは550万～700万位だった。残業代・退職金は無く交通費は出ない。
所属会社は営業も事務も居ない小さな所帯のフリーの集まりのような所で、会社の運営に必要な金額をある程度毎月納めれば良い会社だった。
仕事がなくなれば自分、もしくは他社員の人脈で仕事をとってくる方式。
フリーで居るよりは仕事を取りやすく、単価も上げやすいので一応会社の所属にしているだけの所だった。
それでもすごく世話になった。
私はやる気が無いプログラマだった。オフの時間にプログラムの勉強をしたことなんて殆どないが30歳、35歳の限界説を越え、45歳まで働けた。
これはそんな元ニートの高卒45歳、多重派遣の底辺プログラマの退職エントリ。
はてなのIT技術者諸氏はオフの日にも日々勉強をしているようで。
◯◯出来る人が居ないか？と聞き回る営業を見ていると多重派遣のSESとはいえ業務時間内に勉強させろと私は思う。
技術の勉強の話になると途端に何プペる？のような、仕事の為の無給勉強時間当たり前のように語られる事がやる気の無い私にはついぞ理解することが出来なかった。
足に鎖でもついてるのかね。私と一緒だね。
45歳で年収300万円多重派遣の彼は問題児なのかもしれないが、私よりはやる気があるプログラマなのではないかと思う。
退職までずっとプログラムを書き、テストをしていた。たまに客に直接要望を聞いて仕様書に落とすこともした。
C/C++・Java・各種Shell・VB/VBA・SQL、UNIX/Linux・Windowsサーバーでなんとなーく仕事をしていた。
プログラムは他の人が書いたプログラムを流用しまくって書いた。
ざっくりな話になるが、私より出来る人はわんさか居て、私より出来ない人・問題児が2割は居た。後者の彼らのおかげで私は仕事があったのだ。あと、東京だからあったのだ。
人並以上の理解をしていたのはLinuxの構造くらい。仕事でカーネル層に潜り込み、デバイスドライバの改造をしなくてはならず、月350時間くらい働いているうちに身についたものだ。
当時居た会社は年俸制という糞システムだったので1円も残業代は出なかったが。
全く知らない技術が使われている新しい現場に上位プロパー会社の営業に売りに出されることはままあった。
現場の人にさも「解ってます!」みたいな面で面接をし、何とか切り抜けることは出来た。このときばかりはいやいやながら上辺だけを勉強した。無給でな。
解っている事でも残業が沢山降ってきそうな場合は「ちょっと私には難しいですね・・・」「「いやー、解らないですね。。」と出来ない振りをする度量もついていた。
仕事は”出来る（都合の良い）いい人”に回ってくるし、仕事をしてもめったに単価を上げてくれないし、切られる時は切られる。
30歳を越えたあたりから必要な時は定時丁度に上がる精神的な技術も身についた。
それと同時にここ10～15年はブラックなIT業界でもようやく過残業を減らそうという機運が増えてきたように思う。
ライブやイベントにも足を運べるようになり、推しに投資が出来るようになった。
おそらくまだ10年はプログラマとしてなんとなく生活出来たのだろうと思う。
「あいつ、そこまで出来はしないけれど居ないと困ることもあるんだよなぁ」位のポジションで。
あるいはもう少しやる気を出し、転職をし、上位層で働くことも出来たのかもしれない。
・そしてその日、”1人日”以上の仕事が割り振られる。残業しても終わらない
・翌朝で何故おわっていないのか？を問い詰められる
・仕事のタスク割り振りが多すぎて終える事は出来ないとお伝えしましたが？と反論
・その状況で、空いている時間にやっておいてくれと新たなタスクが振られる
・空いている時間とは？と聴いてみるが、コンパイルしている1分の時間に少しづつといわれ、そんなの出来るわけ無いですよね？。どこに空いている時間があるか教えて下さい。
と、毎朝そんな問答を繰り返していた。
改善をする気もおきなかった。早く次の現場に行きたいなという事ばかり考えていた。
そして気づいた。この仕事にようやく私は飽きたのだと。
子供も数年前に生まれ、子供が成人するまでこの仕事をするのも耐えられないと。
そんな時に副業のほうを本業にする決意をした。会社を辞め、起業をした。
今は全く別業種の業界で働いている。この先うまくいくかは良くわからない。
3次請け、4次請けの会社に居たので理不尽やパワハラには事欠かなかった。
まだ若手の時、鉄砲玉として使われた事があった。
フロッピーを本番端末のあるセンターに密かに持ち込み、定例メンテナンスの振りをしてシステムを黙って更新するという密命が若手の私と、他社の派遣PGで新人のK君に与えられた。何度も。
かばんの奥にフロッピーを隠し、かばん持ち込み検査で検査員にばれないようにし、潜り込む。メンテナンス用の作業IDを使用して黙ってシステムを更新するというのを繰り返し行った。
今考えると下手すると裁判沙汰なんじゃないだろうか。しかも見つかったら責任を取らされるという。
テンパった彼は入館証ではなく、隠していたフロッピーを検査員に見せつけたのだ。
だが、早朝ということもあり、検査員がほぼ寝ていたので問題なく通れてしまった。
今思うとあの時は首の皮一枚で大丈夫だったんだなと。
大手家電メーカーの工場で仕事をした時、プログラムの仕事なのに作業服をまず”自費”で買わされた。作業服いらねえだろう。
工場内にある窓の無いプレハブ小屋が開発現場だった。人権が無ぇ。ファーウェイの工場にはヨーロッパの街並みが再現されているらしいが。
この現場は電機メーカーのIT子会社D社からE社に投げられ、部屋に私以外だと窓際管理職のD社社員１人とE社の人間しか居なかった。
何故、E社の人間の中に私1人だけ他社の開発要員が入るのか？
入ってすぐに理解した。担当するシステムが1人だけで長く開発していたシステムで、スパゲティすぎて破綻しかけているのだ。
これを開発し続けられればヨシ、破綻したら私の（会社の）せいということにしたいのだ。
入って1週間で営業にコレはダメだと、早く抜けさせてくれと直訴した。
結局抜けるのに4ヶ月かかったが、その間、本当に酷い日々だった。
小さな改修が多く、納期は1週間か2週間毎にやってくる。だが仕様を投げるD社の人が鬱で会社にあまり来ない。他のD社の人に聴いても何も解らないという。
1週間の仕事で金曜日納品なのに、木曜日の夕方に2日酔でやってきた担当者に仕様を聞き出し、金曜日に意地で納品するも、気に入らないところがあったらしく「前担当者よりスキルが低いですね～」と言い放たれた。精神の苦行だろうか。
私の抜けた後、E社の別な人間が担当するも無事破綻しかけているという話は後ほど聞いた。自分のスキルでは本当にギリギリだった。危なかった。
高校卒業後はニートだった。猫と母としか会話をしない２年を過ごした。
その後、大手新聞社とオペレーター派遣会社が共同で作っていた文科省認定ではなく定期の学割も効かない街のパソコンスクールに通った。
教師は二種(基本情報)も持っておらず、業界歴は1年だけで環境変数も理解していなかった。
その学校で多重派遣という底辺で生きる技術者の卵に他の20名と一緒になった。
文科省認定の専門学校の情報処理科では少しマトモに勉強すれば大手SIerや商社の子会社の「何ちゃらソリューション」に入れる事も多い。
アホの一つ覚えのように大手の子会社は「何ちゃらソリューション」なので、「何ちゃらソリューション」というIT会社を見たらセンスの良い経営者が名付けた何処か大手の子会社だと思って差し支えない。あとイノベーションとかな。イノベータとかな。
就職氷河期の真っ最中に地方中核都市で就職をしたのだが、入社直前に東京勤務になった。
会社からは15万円の引っ越し資金だけが支給された。氷河期の3月に転職は出来なかった。
親に敷金礼金4ヶ月分を負担してもらい、親父に秋葉原の石丸電気で家財一式を買って貰った。
SES企業はまず新人教育の当たりハズレががある。ハズレのほうが多い。
派遣法の隙間をついて、たった1人で新人が派遣されてくる事も多い。彼らの大体は苦労を強いられている。
私は運良く同じ会社の人が沢山居る現場に入ったのだが、教育担当が想像を絶するパワハラマンだった。とにかくどんなことにもキレる。
ある日個室に呼び出され「お前は田舎に帰って缶詰工場で働け。なるべく頭の働かなくて良い仕事を選んでくれ。業界にいると迷惑だ」と言われてしまった。
親に学校に通わせて貰い、引っ越し代も払ってもらったのに使い物にならないと言われたときの絶望感は大きかった。
地下鉄の電車がホームに入ってきた時、ホーム下にふと吸い込まれて行きそうになり、寸前でハッとなり鼻先を電車がかすめていった。
知らないおばちゃんに「しっかりして！」と怒られた。都会の人も優しい。
それ以降、他社でも同じチームの新人には丁寧に接していた。私はまだ恵まれていた方なのかもしれないと思うこともままあった。
その家電はTronからLinuxにOSが切り替わり、開発・コンパイル用のソフトウェアのシミュレーターが新規開発となった。
Linuxのカーネルプログラミングが必要となり、日本語の文献もインターネット上の文献も少なく、オライリーの洋書（現在は日本語版もある）を取り寄せて読まざるを得ない状況だった。
英語は全く出来ない＆私が作るとなると当然開発は遅れた。
私はカーネルプログラミングなんて当時はしたことが無かったし、集められた人員もLinux上でC言語の仕事をしたことがある。くらいの人員が集められたのだ。
単価が安い人しか使ってはいけないというルールで運用されていたらしい。
苛立った家電メーカーの”部長”が私を広いフロアの大人数の前でこう叱った。
「こいつ全然解ってないじゃないか！！なんでこんなのにやらせているんだ！！」
中国出張で散々おねーちゃんを買った自慢をしていた糞みたいな人間に罵られるのである。
月単価55万で350時間働かされ、残業代は1円も出ずである。誰もフォローをしてくれなかった。
徹夜が3日目に突入した午前3時、役職付きが私のPCの後ろで「まだ出来ないのか？」と15分おきにやってくる。
何とか完成はさせた。恐ろしいことに若かった当時は満足感をそれなりに得ていた。
精神的に色々と凹んでいた時に励ましてくれたのは中国人の同じ派遣の人だった。
大卒の育ちの良い中国人派遣技術者が沢山居たが、彼らは本当に性格がまっすぐだ。彼らが私の中国感を大分良くしてくれた。
（ずっとメッセンジャーばかりやっている連中もいたが）
彼らのような有益な人材が来てくれる時代があと何年あるのだろうか。
私は所属未定のまま倒産した次の日も、土日も何故か働いていた。
自分が働かないと他の人が倒れてしまうと当時は考えていたし、ようやく仕事が出来るようになって謎のやりがいを感じていた。
そして、翌週、中間の会社から流石に所属未定はマズイのでフリーとして契約しましょうと言われたのだが、単価の話なんて当時若造だった私には解らないのである。
結局、300時間以上働く中、残業代無しの45万円固定と言われるまま契約をしたのだが、
当時の私には多い金額に思えていたものの、都内のフリーの技術者としては当然低すぎる金額であった。
忙しい中、アドバイスを貰う余裕もなく、無知のために中間会社の狸親父に低い金額で契約させられたのだった。
みなさんは自分の単価くらいは知っておいたほうが良い。
賢い同じ会社の同僚は失業手当で半年間遊んだか、会社契約と同じ単価でフリーとして契約していた。
余談その2、当時なんとなく興味を惹かれて当時流行っていた日本礼賛本を読んでみた。
国産OSのtronは携帯電話で世界を席巻！！みたいな事が書いてあったが、その本が出ていた頃、携帯電話のOSはLinuxとSymbianで締められていたのを知っていたので興味深く読んだのを覚えている。
他にも
「1次請けが私の単価を上げてくれても中間会社が搾取し、私には全く反映されない話」
「野田がドモホルンリンクルのバイトのように円高を注視し続けた時、円高＆オフショアブームで単価が2年で2回減った話」
「中間会社にオフショア開発の失敗の後始末を手伝って欲しいと言われ、現場をインフルで倒れた振りをして休んだ話」
「5000円の著作権フリー音源をシステムに使用するのに数百万かかった話」
「メモリ枯渇エラーが頻発したのに数百万以上のコストをかけて打ち合わせをする虚無の話」
「メモリ初期化エラーが頻発した時に、解決方法としてとんでもない方法を提示され、阻止した話」
「15万円のPCが60万円で導入される仕組み」
「入社初年度の忘年会の一次会が新宿の有名なゲイのショーパブで、他の社員と会話も無く終わった話」
「無呼吸症候群で猛烈な睡魔との戦い、現場で怒られるようになり、睡眠薬で生活リズムを取り返した話」
「大手会社のコンプライアンス啓蒙画像に著作権違反を発見した話」
「キレる、人前でイライラする人とは働きたくない話」
「某銀行の開発子会社の美人率が高い・銀行員の婚姻率の格差社会の話」
などなど考えていたが長くなったので終わり。
多重派遣先は色々なキャリアの人が多い。元ホスト、元キャバ嬢もいれば元医師の中国人、元アニメ会社勤務、元美容師、元寿司職人等の転職組も多い。
以前いたプロジェクトの有名SI企業のPMもSES上がりの元寿司職人だった。
SESは就職の壁が低い。そこを足掛けとして転職し、さらなる転職で大手や大手子会社に転職するのは悪くないキャリアプランの一つなのかもしれない。
SESの会社も玉石混交なのでまずは良いSES会社に入るのは大事だし、多重派遣は改善されてほしいが。
何が書きたかったのか忘れたし飽きた。
業界からやる気の無い45歳が1人減り、業界は少し平和になった。
追記：続編を書きました。
https://anond.hatelabo.jp/20210131035752
Permalink |記事への反応(23) | 00:19
Webエンジニアの技術確認って、知識や経験が多方面に渡るから難しいと思ってる。
Webアプリ作れます！と言って完成物だけを見るとたしかにそれなりのができてる。
もちろんテストはない。動けばいい。
N+1やSQLインジェクションが埋め込まれてる（後者はフレームワーク側でほぼ無いが）。
Gitは漢のmaster(main)一本だし、rebaseはできない。何かgitでトラブったら全消ししてcloneし直す。
デプロイもHerokuコマンドをよく分からず打ち込んでるだけ。ちょっと凝ったことはできない。
データベースも大きなExcel程度と考えていて、一つのテーブルに全部のデータを入れる漢のスキーマ。
コマンドも例えばgrepやfindを使えない。XXenvの使い方がわからない。何でもかんでもsudoをつける。
vimが使えないからなんかのはずみでvimの画面になったらパニックになる。
まだまだいろいろあるけど挙げたらきりがない。
となるとどこかで線引きをしなければいけないけど、その線引きの一つの手段が対面での会話の内容、受け答えの態度だと思う。
