「設定ファイル」を含む日記 RSS

はてなキーワード: 設定ファイルとは

2023-08-13

anond:20230813185851

引っかかる記事なんだよね。環境設定ファイルの読み込みをするときって、けっこう警戒するプログラマーって多いと思うけどなー、と思った。フランス語というよりも、文字列の数値変換って気を使うよなー、ってね。どこで使うん、そのサブルーチンは?と考えてしまう。

2023-07-22

anond:20230720202519

そこで彼は、様々な決まり事や数値を一切固定で埋め込まず、あらゆる項目を外部の設定ファイルで変更できるようにした。

新規外部ファイル作成するための作業内容

外部ファイル名の採番

稟議書作成して外部ファイル名の採番をライブラリアンに依頼する。稟議にはPL、PMCIO承認印が必要

外部ファイル作成作業

本番サーバー新規ファイル作成する必要がある。ファイル作成バッチ作成レビューを受ける必要がある。

本番サーバーは高セキュリティエリアにあるため入室申請必要

外部ファイル管理手順の作成

外部ファイルメンテナンスサバ部門が行うため、消えてしまった場合不正な値が設定された場合リカバリ手順を作成し、サバ部門承認を受ける必要がある。

役員レビュー

上記すべての手順について、役員の最終認証を得るためにレビュー会を実施するひつようがある。

飲み会

役員レビューのあとは当然呑み会が設定されている。レビューで指摘がなくても呑み会で覆る可能性があるので油断できない。

2023-07-20

コーディングでよくある話

若い開発者が、1つの業務プログラムの新担当を任された。

この業務の処理手順は、数年ごとに多少の変更が入り、今回も、その対応が彼の仕事だった。

彼が、前任者が作ったソースを開いてみると、それはごく単純に業務手順書をプログラムに置き換えたようなもので、

固定値がそのまま文中に記述(マジックナンバー)されていたり、お世辞にも格好いいとは言えないものだった。

彼は考えた。「数年ごとに変更があるのがわかってるんだからもっと変更に柔軟に対応できるようにしておくべきだ!」

そこで彼は、様々な決まり事や数値を一切固定で埋め込まず、あらゆる項目を外部の設定ファイルで変更できるようにした。

プログラムは完成し、彼は運用者と次の後任者に自信満々で言った。

「今後は、業務手順に変更があっても、プログラムビルドし直す必要はありませんよ!設定ファイルで設定を変えるだけでOKです!」

さて、その数年後、実際に業務手順に変更があった。

運用者は設定ファイルを変更したが、うまく正しい結果が出ない。

バグが出てしまたか?と、後任者はソースを開いてみて愕然とした。

そこにあったのは、様々な設定項目に対応するための、膨大なif文ブロックの塊だった。

ソースの大半は、「将来的にこの設定が変更されたら」に対応するための、使われていない行。

設定の組み合わせパターンは膨大になり、全ての分岐カバーテストはされてはいなかったのだ。

結局、後任者はこのプログラム修正を断念。

再び、現在業務手順だけを、そのまんまプログラムに落とし込んでいった。

ソースは遥かに短くなった。

かにこの方法では、業務手順変更がある度に、プログラムを直してビルドする必要があるが、

そもそもプログラム言語というものは、「手順を明快に記述できる」ように発達してきたものなので、

手順書そのもののようなその新しいプログラムは、誰でも簡単理解して修正できるものになっていた。

【教訓】将来の変更に対応するための「汎用性」「柔軟性」を上げようとするのは間違っていないが、

 実際に来るかもわからない将来に備えてプログラムを複雑化するのは間違い。

 「~が変わった場合はここを変えてください」とコメントに書いておくくらいでちょうどいい。

2023-07-05

anond:20230705084305

Github Copilotでそこまで生産性が上がってる感じがしないな。

AIが生成したコードを読みながら、どこが間違えているのかを試行錯誤するよりも最初から自分で書いたほうが早い。

テストコードみたいに意図的に大量のボイラプレートを書く必要がある場合は役に立つ。

あとは設定ファイルとかも良い感じに書いてくれる。

2023-05-17

Github Copilotっていうほど使えるか?

コードを書いている時間より読んでいる時間のほうが圧倒的に長いからそんなに便利になった感じがしない。

型推論による補完が既にあるし今のところはそれに頼ってることが多いな。

新規で何か書くときdocker-composeのような設定ファイルを書く時はわりと役立ってる。

2023-02-18

Linuxサポートがしんどすぎる

PCスマホタブレット等のIT機器ヘルプ対応をしているけど、このうち対応が最も面倒なのがLinux

Windowsmacよりも件数はかなり少ない代わりに、対応難易度の高さは飛び抜けている。

それもうオンサイト対応じゃなきゃ解決できねーよみたいな内容が極端に多い。

どういう使い方で、どんなソフトウェアをどのように入れたかにより、OSの奥深くにある基本的な設定が書き換わるケースもあるし、もちろんディストリビューションバージョンごとの違いもあるしで、
設定ファイル修正方法コマンドを送ったくらいでは解決せず、挙げ句

「このコマンドを実行してください」

解決しませんでした」

「このファイル修正してください」

解決しませんでした」

というやりとりが延々続くだけになり、手に負えなくなってサポート打ち切りになるケースがほとんど。

というかサーバじゃなくデスクトップで使っているなら、そしてそんなとこまでこっちにやらせるなら今すぐフォーマットしてWindows入れろやボケ!!!

と言ってやりたくなる。

なんでこう、Linuxトラブルはどいつもこいつもやたらややこしいんだか。

正直Linuxヘルプ対応をするたび、Linuxがどんどん嫌いになっていく。

まじでサポート対象外にしたい。

(追記)

サポートってどんなサポート?という質問があったけど、本当にごく普通クライアントPCトラブル対応を、いわゆる情シススタッフとしてやっている。

ちな会社社員数1万人くらいで、自分はそこの情シスの中の、本社社員IT機器サポートするチームのメンバー

とはいえ対応時に見ているのは社員PCだけじゃなく、場合によってはその社員接続した際のDHCPDNSFWログはもちろん、L2・L3スイッチRADIUSだって見に行く。

それでもトラブルの原因がわからないときがあるので、ネットワークのチームやサーバのチームに相談することもしょっちゅう

なお自分はもともと、開発・構築・運用と使い回されてきたタイプで、開発一つ取ってもWindowsアプリiPadアプリWeb系にとこなしてきた。

あとデスクトップLinux大学いた頃に慣れ親しんでいた(レポート論文を書くくらいには使っていた)。

で、そんな君みたいな人を待っていたんだ!と言われ引き抜かれたのが今の仕事というわけ。

ただLinuxサポートにここまで手こずるのは想定外だったわ。

やはり専門知識という意味ではLPICくらいは取ったほうがいいのか?と思っていたり。

(追追記)

ウチの会社デスクトップLinuxを使っているのは(macもだけど)主にR&D部門と、そこから転属or昇進した人達

(一方でバックオフィス系は、サポートが最も楽なリース契約WindowsPCだったりする)

このうち問い合わせてくるのは、大体が

  • とても詳しい人
  • とても詳しい人から退職後に実機を引き継いだ、あまりよくわかっていない人

のどちらかで、このうち後者については部門ガバナンスどうなってんだと思わなくもない。

結果、対応でよくある風景

  • 「もし***が○○○という設定になっていたら▲▲▲に修正してもう一度ご確認ください」

 「それもう試した」

 →どこまで何を確認たか要点だけでも教えてくださいよ…このやり取り、普通時間無駄ですよね?

 「ありませんでした」

 →「ありませんでした」じゃねえ探すんだよ!ログがなきゃ原因特定できないんだが?そんなこともわからないでLinux使ってるのかよ…。

こういうやり取りが延々繰り返されるので、目に見えてMPが削られるという愚痴でした。

2022-12-14

登山道具貧弱でも死んでない理論、本番サーバーログインしてvi設定ファイル書き換えて再起動していた頃を思い出した

2022-12-02

最近オープンソースソフトウェア傲慢

githubとか見てて思うけど最近オープンソースコードって余計なものがあまりに多い

ビルド自動化ツールとか仮想化コンテナとかIDE設定ファイルとかあってもあんまり嬉しくない

結局そのせいでプロジェクト肥大化してコードも見づらくなるんだからつらいよ

2022-09-06

anond:20220906222204

9x→XP(2k)で動かなくなったアプリが多々あったのは確かだけど、それはファイルアクセス権限問題というよりは、アプリパフォーマンス最重視で設計されていたりレガシーコードが悪さしたりして古いシステムコールを多用してたのが原因だったのではないかなと思う(起動した瞬間にハングアウトしたり画面が化けたりするゲームがあったことを覚えている)

XPSP2でファイアウォールOSデフォルト機能として搭載されたけど、それはアプリインターネットアクセス規制するためのもの管理者権限での実行を制約するものではなかったはず

Program Filesフォルダ設定ファイルを保存するのが容認されなくなたのはVISTAになってからじゃないか

2022-08-01

anond:20220801180910

管理画面のどこにもその項目がないのだ

おそらくサーバー上のどこかに設定ファイルか何かを置いていたんだと思うが、

俺の権限だと怪しいフォルダを開くことすらできない

たぶんDBからSQL抽出だと思う

会社潰した

一昨年の末、某WEBサービス運営者として前任者逃亡状態入社した

俺のメインの仕事広告配信だった

管理画面から設定を行い、サイト内の所定の場所広告を表示させる

もしくは会員向けの広告メール送信する

広告によって性別とか年齢で送信先を絞ったり、地域によって掲載内容を変えたりと細かい指定が入る

しかし前任者がマニュアルも残していかなかったので、この振り分けができなかった

管理画面のどこにもその項目がないのだ

おそらくサーバー上のどこかに設定ファイルか何かを置いていたんだと思うが、

俺の権限だと怪しいフォルダを開くことすらできない

上司に状況を説明たかったが、上司は「アウトルックって何?」というタイプ人間だった

というか社員全員そういうおじさんだった

わかる人間はすでに全員逃げていたのだ

社内全体で状況を共有して対処すべきだったが、説明死ぬほど面倒だった

なので俺は責任ある役職人間を捕まえて

「引き継ぎ不足で、現状指定されたセグメントに配信するのが困難です。ですので当面の間、可能範囲広告主の要望に近い絞り込みを行って配信して、要望通りに配信していることにしませんか。苦肉の策ということで。もちろん平行して解析を進め、早急に従来どおりの配信を再開できるように努めます

ということをもうちょっとそれっぽく言い、「じゃあ、それでいこう」と了承を得た

ちなみに「可能範囲で」とは言ったが、可能なことはなにもないので俺はすべての広告を全会員にむけて投げ続けた

嘘は言ってないよな

全員に送ってるわけだからはじめの頃は反響も大きく、広告からも高評価だった

しかし徐々に反応が悪化した

まあ同じサービスから一日何通も広告メールが飛んできたらそうなるよな

メルマガ会員数も急激に減少の一途を辿ったが、俺はそれを誰にも報告しなかった

そして引き続き全ての広告を全員に投げ続けた

そのうち客から効果が合わないと怒られるようになり、補填としてさら配信回数を増やした。

これにより眠っていた潜在ユーザーも退会していき、ついに広告収入モデル崩壊した

効果の薄い広告メールを大量に配信するだけのゾンビとなった某WEBサービスそれから半年弱の間赤字を積み上げながら生存したが、ついに立ち行かなくなり倒産が決まった

サービス終了の日も俺は5回の全通広告メール配信した

とても感慨深かった

社長は俺に対して何度も何度も謝ってくれた

「安い給料で1人でずっと頑張ってくれたのに、持ちこたえられなくてごめんな」と

まあでも半分くらいは俺のせいだと思うし、こっちこそごめん、と心のなかでつぶやく増田なのだった…

2022-07-29

ソースコード公開すると化けの皮が剥がれるからインフルエンサー諸氏はやめた方がいい

イキってるエンジニア自称)がイキりすぎてコード公開すると化けの皮が剥がれるからやめたほうがいい。

炎上にすらならないということは、

・駆け出しエンジニア(笑)の人はコードが読めない・見ない

普通エンジニアはイキりエンジニアそもそも無視

ということなんだろう。

2022年にもなってJSでvar使ってたり、環境変数設定ファイルを.gitignoreに入れないでAWSキー公開してたり、インデントやLintがぐちゃぐちゃだったりもうひどい。

もちろん実装自体もひどい。

2022-05-23

いきなりメイクを押し付けられる理不尽

sudo make install

しないと動作しないとかしねと思います😫

よくわからんところに設定ファイル作ったり、

ファイルシステムを汚すな!😔

2022-05-05

anond:20220505215545

いや。AWSだとLinuxネットワーク周りの知識不用になるってことは別にないけどってだけ

 

ただ、オンプレLinuxが主流の時代ならみんな理解してたのか?と言えば別にそんなことは無いです

オンプレLinuxが主流の時代でも仕組みをよくわかっていない人によって動いてるサーバーはたくさんあった

そもそも学習目的以外でゼロからカーネル設定ファイル弄ってサーバー構築とかなかったです

 

サーバーエンジニアネットワークエンジニアセキュリティエンジニア・社内インフラ担当(社内SE)呼称はなんでも良いが

彼らの作った設定をコピペやぞ(ひどい場合技術blogからコピペ)

Linuxネットワーク周りをまったく理解していなくてもAWSコンソールポチポチしてサーバーを立てられるのと同じで、

理解してなくてもコピペで割と動いてたよ

サービスの稼働監視するのは別チームでおすし

anond:20220504211823

★★再追記

レンタルサーバは、自由度が低くてストレスになるからやらない。SQLでwith使いたいかMySQL8をって言ってもさくらレンタルサーバじゃ無理なんでしょ? あと同居利用者のせいで高負荷ってのも避けたい。そこを気にしない人はレンタルサーバでいいと思うよ。

あと LB $0.025/h だった。月2000円くらいか

追記

LBは独自ドメイン+自動更新無料SSL証明書のためね。Cloud Storageの無味乾燥ドメインでいいなら、SSL自動かつ無料でほんとに月数円。

-------

もうねめんどくさいんだわ。もちろん以前はそうやってたよ。

PHPだのApacheだのMySQLだのインストールしたり設定ファイル置いたり、

脆弱性対応したり、SSL証明書更新したり、一応落ちてないか無料監視サービス使ったり。

でも仕事ならともかく、趣味からこそこんなことやりたくないじゃん。

なので、コンテンツは Cloud Storage に置く。

Cloud Load Balancing も使う (無料 SSL 証明書のために)。

認証必要なところは Cloud Identity で。

動的部分は Cloud Functions で。

AWS なら S3+ALB+Cognito+Lambda だな。

そうしておけば、放置できる。自前で立てたマシンインスタンスもないから落ちてるかどうかとか気にしなくてもいい。負荷も考えない。クラウド様がよきにはからってくれるさ。たまにクラウド障害あるかもしれないけど、Google なり AWS なりが頑張って直してくれる。

って感じ。

ちなみにこちらは 1日数十アクセスの過疎サイト独自ドメイン+自動SSL証明書にするための Cloud Load Balancing に 4000円くらい払ってる。それがなければ月数円。

2022-04-21

anond:20220421121122

viエディタと同様、キーボードのみで操作されることを前提としていたため、キーボードのみですべての操作可能になっている。その基本的操作方法viと同じで、状況に応じてモードを使い分けることでテキスト編集していき、小さなコマンドの組み合わせをその場で作ることによって多種多様機能を実現する。

他のエディタとは操作方法がまるで異なるため、一通りのテキスト編集作業ができるようになるまで慣れが必要となる。しかしながら、一旦慣れてしまえば軽快なテキスト編集ができるため、数多くのVim愛好家が存在する。Vimの他の機能と併せて、プログラムコードシステム設定ファイル編集するのに特化しているため、特にプログラマーシステム管理者利用者が多い。

https://ja.wikipedia.org/wiki/Vim

なるほど。

あとはユーザー数の数の論理かな。

利用者が多ければ汎用的で、自分スキル他人の役に立つ。

そうでなければ少数の職人芸になって、老人の自己満足になってしまう。

vi/vimがほかのエディタよりユーザーが多いのかは知らないけど。

あとは、viメモリが数十KB時代に、軽く動くことを想定して作られたってことがキーポイントかもね。

今時軽いからといってWindows2000使う人いないでしょ。

それらを総合的に見て、アホか賢いかって価値判断になるかな。

個人的には、慣れてるから使う、古くからあるから使う、ってのは、思考停止のアホに見える。

そういうのはITじゃなくて土方行ったほうがいい。

2022-03-16

anond:20220316202807

前提として、サーバ側のDBの中身が漏洩したと同時に、プログラム設定ファイル、丸ごと全部漏洩したとみなしている。

プログラムDB上のパスワードをどのように処理してるか丸見えになる。

複合できるということは、プログラムの手の届く場所に鍵があるということ。

その鍵がユーザごとに違っていようが関係ない。そのプログラムを通せば複合できるわけだから

複合した結果、元のパスワードを「瞬時に」出せる。

その元のパスワードを使って、正規ユーザのフリをして悪いことができる。

さてハッシュ場合、bcryptなどではソルト付きハッシュ値になってる。

ハッシュ値ごとにソルトが違う構造になってる。

ハッシュなので「時間をかければ」、そのハッシュ値になる値を検索できる。

元のパスワードと同一であるかどうかはわからない。(同一でなければバレる可能性が高まる

1ユーザごとに時間をかける必要がある。

ここである程度時間を稼げるので、サーバ管理者側にサービスを停止したり、パスワードを全部向こうにするような時間の余裕ができる

2022-01-25

本のまとめ

--

この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。

1章

コンテナとは】

他のプロセスとは隔離された状態OS上にソフトウェアを実行する技術

コンテナ利用のメリット

環境依存から解放

コンテナにはアプリの稼働に必要となるランタイムライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリ依存関係をすべてコンテナ内で完結できる。

依存関係を含めたパッケージリリース単位となる

環境構築やテストに要する時間の削減

優れた再現性ポータビリティ

全ての依存関係コンテナ内で完結するため、オンプレでもクラウドでも起動する。

ステージング環境テスト済みのコンテナイメージプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテスト必要工数を削減できる。

リソース効率のアップ

サーバー仮想化では、仮想マシンレベルリソースを分離し、ゲストOS上でアプリが起動する。つまりアプリだけでなく、ゲストOSを動かすためのコンピューティングリソース必要

一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。

Dockerとは】

コンテナライフサイクル管理するプラットフォーム

アプリコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。

アプリソースコード + Dockerfile

↓ buildでイメージ作成

イメージ(アプリケーションと依存関係パッケージングされる。アプリライブラリOS)

shipイメージの保存

レジストリに保存

run コンテナの実行

オンプレクラウドなどで起動

Dockerfileとは】

イメージを構築するためのテキストファイル

このファイルコマンド記述することで、アプリ必要ライブラリインストールしたり、コンテナ上に環境変数を指定したりする。

1章まとめ、感想

コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンド設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。

2章

AWS提供するコンテナサービス

コントロールプレーン

コンテナ管理する機能

コントロールプレーンは2種類

ECSとEKSがある。

ECS

フルマネージドなコンテナオーケストレータ。

オーケストレーションサービスであり、コンテナの実行環境ではない。

ECSの月間稼働率99.99%であることがSLA として保証

タスク

コンテナ動作するコンポーネント

タスクは1つ以上のコンテナからなる

アプリを起動するためにはコンテナ必要

タスク定義

タスク作成するテンプレート定義JSON記述

デプロイするコンテナイメージタスクコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。

サービス

指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサータスクを実行するネットワーク指定

クラスター

サービスタスクを実行する論理グループ

データプレーン

コンテナが実際に稼働するリソース環境

2種類ありECSとFargateがある。 Fargateに絞って書く

Fargateとは

サーバーレスコンピューティングエンジン

AWSのフルマネージドなデータプレーンとして定義されている

コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する

Fargate メリット

ホスト管理不要であること

サーバーのスケーリングパッチ適用保護管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる

Fargate デメリット

価格EC2より高い。

利用者コンテナの稼働するOSには介入できない

コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる

ECR

フルマネージドなコンテナレジストリ

コンテナイメージを保存、管理できる

コンテナが利用されているサービス

Lambda

・App Runner

Lambda

 利用者コードアップロードするだけでコードを実行できるサービスAWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス

App Runner

 2021年5月GA(一般公開)となったサービスプロダクションレベルスケール可能webアプリを素早く展開するためのマネージドサービスGithub連携してソースコードをApp Runnerでビルドデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。

 ECSとFargateの場合ネットワークロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識必要になる。App Runnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である

ECS Fargateを利用した場合コスト拡張性、信頼性エンジニアリング観点

コスト

EC2より料金は割高。ただし、年々料金は下がってきている。

拡張性】

デプロイの速度 遅め

理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる

理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。

タスクに割り当てられるエフェメラストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要場合はEFSボリュームを使う手もある。

割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリ要求するホストとしては不向き

信頼性

Fargateへのsshログインは不可。Fargate上で起動するコンテナsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境sshの口を開けるのはリスキーである。他にSSMセッションマネージャーを用いてログインする方法もあるが、データプレーンEC2の時に比べると手間がかかる。

しかし、2021年3月Amazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。

エンジニアリング観点

Fargateの登場からしばらく経過し、有識者経験者は増え、確保しやすい。

システム要件確認

多数のユーザーに使ってもらう

可用性を高めるためにマルチAZ構成を取る

CI/CDパイプライン形成し、アプリリリースに対するアジティを高める

レイヤで適切なセキュリティ対策不正アクセス対策認証データの適切な管理ログ保存、踏み台経由の内部アクセス)を施したい

2章まとめ、感想

AWS提供するコンテナサービスはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理不要インフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である

3章

この章では運用設計ロギング設計セキュリティ設計信頼性設計パフォーマンス設計コスト最適化設計について述べている。

運用設計

Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計不具合修正デプロイリスク軽減のためのCI/CD設計必要である

モニタリングとは

システム内で定めた状態確認し続けることであり、その目的システムの可用性を維持するために問題発生に気づくこと

オブザーバビリティとは

システム全体を俯瞰しつつ、内部状態まで深掘できる状態

オブザーバビリティの獲得によって、原因特定対策検討が迅速に行えるようになる

ロギング設計

・cloud watch logs

他のAWSサービスとの連携も容易

サブスクリプションフィルター特定文字列の抽出も容易

・Firelens

AWS以外のサービスAWS外のSaaS連携することも可能

Firehoseを経由してS3やRed shiftOpenSearch Serviceにログ転送できる

Fluentdやfluent bit選択できる

fluent bitを利用する場合AWS公式提供しているコンテナイメージ使用できる

セキュリティ設計

イメージに対するセキュリティ対策

 - ソフトウェアライブラリ脆弱性は日々更新されており、作ってから時間が経ったイメージ脆弱性を含んでいる危険がある。

 - 方法

  脆弱性の有無はECRによる脆弱性スキャンOSSのtrivyによる脆弱性スキャン

継続的かつ自動的コンテナイメージスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリ場合CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャン必要になる。

cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる(スキャン自体は1日1回のみ可能

提供元が不明ベースイメージ使用は避ける

・IAMポリシーによるECRのパブリック化の禁止

 - オペレーションミスによる公開を防ぐことができる

信頼性設計

マルチAZ構成

Fargateの場合サービス内部のスケジューラが自動マルチAZ構成を取るため、こちらで何かする必要はない。

障害時切り離しと復旧

ECSはcloud watchと組み合わせることでタスク障害アプリエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる

ALBと結びつけることで、障害が発生したタスク自動で切り離す

リタイアという状態

AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合ECSは新しいタスクに置き換えようとするその状態のこと。

Fargateの場合アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ整合などが生じて危険

システムメンテナンス時におけるサービス停止

ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能

サービスクォータという制限

意図しない課金増加から保護するために設けられた制限

自動でクォータは引き上がらない

cloud watch メトリクスなどで監視する必要がある。

パフォーマンス設計

パフォーマンス設計で求められることは、ビジネスで求められるシステム需要を満たしつつも、技術領域進歩環境の変化に対応可能アーキテクチャを目指すこと

ビジネス上の性能要件を把握することが前提

利用者数やワークロードの特性を見極めつつ、性能目標から必要リソース量を仮決めする

FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める

既存のワークロードを模倣したベンチマークや負荷テスト実施してパフォーマンス要件を満たすかどうかを確認する

スケールアウト

サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存タスクを停止する必要原則ない。

スケールアウト時の注意

・Fargate上のECSタスク数の上限はデフォルトリージョンあたり1000までであること。

VPCIPアドレスの割当量に気をつける

ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能IPアドレスが消費されていく

スケールアウトによるIPアドレスの枯渇に注意

Application Autoscaling

Fargateで使用可能

Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う

ステップスケーリングポリシー

ステップを設けて制御する

CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意ステップに従ってタスク数を増減させる

ターゲット追跡スケーリングポリシーとは

指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針

ターゲット追跡スケーリングPermalink | 記事への反応(0) | 21:45

本のまとめ

--

この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。

1章

コンテナとは】

他のプロセスとは隔離された状態OS上にソフトウェアを実行する技術

コンテナ利用のメリット

環境依存から解放

コンテナにはアプリの稼働に必要となるランタイムライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリ依存関係をすべてコンテナ内で完結できる。

依存関係を含めたパッケージリリース単位となる

環境構築やテストに要する時間の削減

優れた再現性ポータビリティ

全ての依存関係コンテナ内で完結するため、オンプレでもクラウドでも起動する。

ステージング環境テスト済みのコンテナイメージプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテスト必要工数を削減できる。

リソース効率のアップ

サーバー仮想化では、仮想マシンレベルリソースを分離し、ゲストOS上でアプリが起動する。つまりアプリだけでなく、ゲストOSを動かすためのコンピューティングリソース必要

一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。

Dockerとは】

コンテナライフサイクル管理するプラットフォーム

アプリコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。

アプリソースコード + Dockerfile

↓ buildでイメージ作成

イメージ(アプリケーションと依存関係パッケージングされる。アプリライブラリOS)

shipイメージの保存

レジストリに保存

run コンテナの実行

オンプレクラウドなどで起動

Dockerfileとは】

イメージを構築するためのテキストファイル

このファイルコマンド記述することで、アプリ必要ライブラリインストールしたり、コンテナ上に環境変数を指定したりする。

1章まとめ、感想

コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンド設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。

2章

AWS提供するコンテナサービス

コントロールプレーン

コンテナ管理する機能

コントロールプレーンは2種類

ECSとEKSがある。

ECS

フルマネージドなコンテナオーケストレータ。

オーケストレーションサービスであり、コンテナの実行環境ではない。

ECSの月間稼働率99.99%であることがSLA として保証

タスク

コンテナ動作するコンポーネント

タスクは1つ以上のコンテナからなる

アプリを起動するためにはコンテナ必要

タスク定義

タスク作成するテンプレート定義JSON記述

デプロイするコンテナイメージタスクコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。

サービス

指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサータスクを実行するネットワーク指定

クラスター

サービスタスクを実行する論理グループ

データプレーン

コンテナが実際に稼働するリソース環境

2種類ありECSとFargateがある。 Fargateに絞って書く

Fargateとは

サーバーレスコンピューティングエンジン

AWSのフルマネージドなデータプレーンとして定義されている

コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する

Fargate メリット

ホスト管理不要であること

サーバーのスケーリングパッチ適用保護管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる

Fargate デメリット

価格EC2より高い。

利用者コンテナの稼働するOSには介入できない

コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる

ECR

フルマネージドなコンテナレジストリ

コンテナイメージを保存、管理できる

コンテナが利用されているサービス

Lambda

・App Runner

Lambda

 利用者コードアップロードするだけでコードを実行できるサービスAWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス

App Runner

 2021年5月GA(一般公開)となったサービスプロダクションレベルスケール可能webアプリを素早く展開するためのマネージドサービスGithub連携してソースコードをApp Runnerでビルドデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。

 ECSとFargateの場合ネットワークロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識必要になる。App Runnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である

ECS Fargateを利用した場合コスト拡張性、信頼性エンジニアリング観点

コスト

EC2より料金は割高。ただし、年々料金は下がってきている。

拡張性】

デプロイの速度 遅め

理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる

理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。

タスクに割り当てられるエフェメラストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要場合はEFSボリュームを使う手もある。

割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリ要求するホストとしては不向き

信頼性

Fargateへのsshログインは不可。Fargate上で起動するコンテナsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境sshの口を開けるのはリスキーである。他にSSMセッションマネージャーを用いてログインする方法もあるが、データプレーンEC2の時に比べると手間がかかる。

しかし、2021年3月Amazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。

エンジニアリング観点

Fargateの登場からしばらく経過し、有識者経験者は増え、確保しやすい。

システム要件確認

多数のユーザーに使ってもらう

可用性を高めるためにマルチAZ構成を取る

CI/CDパイプライン形成し、アプリリリースに対するアジティを高める

レイヤで適切なセキュリティ対策不正アクセス対策認証データの適切な管理ログ保存、踏み台経由の内部アクセス)を施したい

2章まとめ、感想

AWS提供するコンテナサービスはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理不要インフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である

3章

この章では運用設計ロギング設計セキュリティ設計信頼性設計パフォーマンス設計コスト最適化設計について述べている。

運用設計

Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計不具合修正デプロイリスク軽減のためのCI/CD設計必要である

モニタリングとは

システム内で定めた状態確認し続けることであり、その目的システムの可用性を維持するために問題発生に気づくこと

オブザーバビリティとは

システム全体を俯瞰しつつ、内部状態まで深掘できる状態

オブザーバビリティの獲得によって、原因特定対策検討が迅速に行えるようになる

ロギング設計

・cloud watch logs

他のAWSサービスとの連携も容易

サブスクリプションフィルター特定文字列の抽出も容易

・Firelens

AWS以外のサービスAWS外のSaaS連携することも可能

Firehoseを経由してS3やRed shiftOpenSearch Serviceにログ転送できる

Fluentdやfluent bit選択できる

fluent bitを利用する場合AWS公式提供しているコンテナイメージ使用できる

セキュリティ設計

イメージに対するセキュリティ対策

 - ソフトウェアライブラリ脆弱性は日々更新されており、作ってから時間が経ったイメージ脆弱性を含んでいる危険がある。

 - 方法

  脆弱性の有無はECRによる脆弱性スキャンOSSのtrivyによる脆弱性スキャン

継続的かつ自動的コンテナイメージスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリ場合CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャン必要になる。

cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる(スキャン自体は1日1回のみ可能

提供元が不明ベースイメージ使用は避ける

・IAMポリシーによるECRのパブリック化の禁止

 - オペレーションミスによる公開を防ぐことができる

信頼性設計

マルチAZ構成

Fargateの場合サービス内部のスケジューラが自動マルチAZ構成を取るため、こちらで何かする必要はない。

障害時切り離しと復旧

ECSはcloud watchと組み合わせることでタスク障害アプリエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる

ALBと結びつけることで、障害が発生したタスク自動で切り離す

リタイアという状態

AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合ECSは新しいタスクに置き換えようとするその状態のこと。

Fargateの場合アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ整合などが生じて危険

システムメンテナンス時におけるサービス停止

ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能

サービスクォータという制限

意図しない課金増加から保護するために設けられた制限

自動でクォータは引き上がらない

cloud watch メトリクスなどで監視する必要がある。

パフォーマンス設計

パフォーマンス設計で求められることは、ビジネスで求められるシステム需要を満たしつつも、技術領域進歩環境の変化に対応可能アーキテクチャを目指すこと

ビジネス上の性能要件を把握することが前提

利用者数やワークロードの特性を見極めつつ、性能目標から必要リソース量を仮決めする

FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める

既存のワークロードを模倣したベンチマークや負荷テスト実施してパフォーマンス要件を満たすかどうかを確認する

スケールアウト

サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存タスクを停止する必要原則ない。

スケールアウト時の注意

・Fargate上のECSタスク数の上限はデフォルトリージョンあたり1000までであること。

VPCIPアドレスの割当量に気をつける

ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能IPアドレスが消費されていく

スケールアウトによるIPアドレスの枯渇に注意

Application Autoscaling

Fargateで使用可能

Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う

ステップスケーリングポリシー

ステップを設けて制御する

CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意ステップに従ってタスク数を増減させる

ターゲット追跡スケーリングポリシーとは

指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針

ターゲット追跡スケーリングPermalink | 記事への反応(0) | 21:45

2021-12-29

anond:20211229192648

うっかり、設定ファイル777 にしてるとか、

いくつもうっかりを重ねないと使えないセキュリティホールであっても、

何万台、何十万台と使われていると、その中に数台は潜んでいると考えてもおかしくないのが現実

2021-11-04

anond:20211104230025

コンテナ時代になって、本当に ps とか ls すらない環境がきたから、もう Vi やら Python が入っているという前提を捨てちゃったね。自分は。一時期のような、BashPython で置き換えるという運動も、systemd やら Kubernetes のような設定ファイルを使ういま、PythonLLデファクトスタンダード時代終焉に近いと思うがね。

2021-08-26

(root) Additional property {service-name} is not allowed

ドッカー今ポーズ?とかいうのがうごかなくなった

何もしてないのに壊れた。と言いたいところだけど多分こないだドッカーをアップデートたからだとおもう

でもあっぷでーとしただけでこわれないでほしい

ググったけいつものようにろくな情報が出てこない

ITってさマジでろくな情報ネットに転がってねーよな。あるかもしれんけどグーグル検索ゴミすぎてヒットしないっていう

とりあえず念力でdocker-comppose.yamlおかしいかもしれないと当たりをつけた。

{service-name} っていうサービスyamlにとうろくしてるんだけど、なんかの手違いでこのサービスの値をうまく読み込めていないのだろうと、直感だけで決めつける

そんでとりあえずyamlふぉーまっとをググってみてくる。

へいしゃかんきょうのファイルyamlルート空間直下サービスをチョクで併記する感じなのだが、ネットで出てくる参考記事にはservice: 要素でくるんでいる

今まで動いてたのが動かなくなるの死ねって感じなので死ねって祈りながら、とりあえずservice:要素をルートに追加して、いままでトップレベル野ざらしにしてた各種サービス要素をservice:の下に入れる

docker-conpose up -d

実行で無事動作しました。

ドッカーアップデートするのいいけど設定ファイル読み込みの後方五巻壊すんじゃねーよかす

なんでいつもいつもエスパー能力使わないと行けないんだよ。このていどの記事ネット上に置いとけバカちんが

ログイン ユーザー登録
ようこそ ゲスト さん