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

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

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

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

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

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

2021-07-29

自分が開発を始めたソフトウェアイスラエル企業の目に留まってそのまま現地に行っちゃった人のお話を読んでいた。

すごいなー→仕事心底楽しそうやなー→自分の実現したいことが周囲から認められて幸せそうやなーまでは思った。

けれども、こーなりたいなーとか自分もいつかのために勉学に励まなくちゃ!って気概まで全く至らなくて

プロ野球選手目指しますとはちゃうんだからと思っても、自分にはもう踏み出す足がないことにため息をついてしまった。

プログラミング嫌い、特にgo言語なにそれおいしいの?原始的で野蛮書くの辛いって口悪しくぶっちゃけたら転職面接で落ちたばかりだ。

実際に似たような業界だけど、プログラマーとしての才能まじでないし、寿司打は一回り年下の後輩にぼろ負けするくらいタイピング遅いし、

正直コーディングよりも、yamlファイル、tomlファイルという設定ファイルもっちり整えてる時間の方が好き。

マネージャー職もリーダーも無理。自分はこのポジむいてないなっていうのはよく知ってる。ソフトバンク行った同僚の残した資料を見てるとこれと同じレベルドキュメント作る自信も皆無で。

...そんなワイでも、もっとお金もらえる仕事いかな。さすがに禿が気になる年頃だし、600万円ほしいな。無理かな。

2021-06-26

ありがとうだいなファイラー

2021年になっても更新してくれてたんだね。

Windows7から10に移行後使えなくなってたから困ってたんだ

まさか2021年になっても更新してるとは思ってなかったんでびっくりしたよ

 

ファイラー重要性はほとんどの人が理解できなくて、職場で使うことはできないが自分PCには入れて使ってるよ

便利だしね。

まあ、移行後にzipやら画像ファイルが開けなくて困ってるけどね。

設定ファイル新しくしてもzipの中身見れなかったのはちょっと謎だったな

2021-06-18

そもそもアルゴリズム本の一冊も読んだことのない人って

FizzBuzzとか書けるの?

この前、PHPプロジェクトで.iniファイル(昔Windowsで使われてた設定ファイル形式)を使わないといけないことになって、ミーティングが開催される事態になって「だれか.iniファイルライブラリもってない?」「○○課の〇〇さんに聞いてみれば?」「なんでPHPで.iniファイルなんだよ」とかいろいろ言ってるのな。

.iniを読み書きする処理なんて、そのミーティング時間で書いちゃえばいいんじゃね?って感じだが。

コピペプログラマって悲惨だわ。

anond:20210617145029

設定ファイル読み込み処理がバグだらけで検収通らないのを構文解析手法導入してまともに動くようにしたとか

2021-06-09

何故 Fastly を使うのか

数ある CDN のなかでも Fastly は圧倒的に優れた特性を持つものだと思うので、障害にかこつけてその優れた点を紹介していく。

キャッシュが消えるのがはやい

CDN とは世界各地にあるキャッシュサーバーコンテンツキャッシュして配信してもらうことで、オリジンサーバーの負荷を軽減したりユーザーへの配信速度を上げたりするリバースプロキシホスティングサービスだが、 Fastly の最大の特徴としてはそのキャッシュが消えるのが速い。普通CDN が数十秒〜数分とかかるのにたいして 0.2 秒で全部消えることが保証されているし、キャッシュにたいしてキーをつけておけば(HTTP ヘッダーに Surrogate-Key って入れるだけ)特定キーがついているキャッシュだけ 0.2 秒以内に消したりということができる。

これにより、 CDN による配信高速化恩恵を受けながら、コンテンツリアルタイム更新していくことができる。 next.js + vercel などはこのあたりをフロントエンドから CDN まで一気通貫提供することでリアルタイム風にコンテンツ更新できるように見せかけているが、 Fastly なら本当になにもかもリアルタイムで出来ることが保証されるので、難しいことを考えなくてもよい。

設定の反映が速い

CDN の設定の反映の遅さというのは Cloudfront とか使っていれば感じることだと思うが、 Fastly なら 5 秒ぐらいで反映される。設定を変更しながらいろいろ検証しているときにこれが地味に嬉しい。

ただし上記特性の代償と言えるのかもしれないが(そうではないのかもしれないけど)、 Fastly は「デカめの配信拠点比較的少数配置する」という構成になっているため、ディザスタリカバリなどの面では不安がある(今回の障害マジで部落ちたのでこれとは関係ない問題だろう)。

Webからの設定が豊富+ツボを抑えている

Web 設定画面からいじれる設定項目が多く、にもかかわらずユーザーに優しく使いやすい。例えばリクエストヘッダーを Fastly 側で書き換えてもらう機能があるのだが、それとは別に Host ヘッダーのオーバーライドの設定は(えてしてよく使うので)別の画面に切り出されていたりする。

いざとなれば Varnish の設定ファイル(VCL)をアップロードできる

大抵のユーザーWeb からの設定画面でできることで満足すると思うが、高度な制御をしたい場合、 Varnish の設定ファイルスニペットアップロードしたり、あるいは設定全体を書いてアップロードする、といったことができる。例えば JWT のデコードVCL でやってしまって、同じ URI にたいして認証済みユーザーとそうじゃない人でキャッシュのだしわけなんてことが Fastly 上でできるようになる。

ただし VCL でいろいろな制御を実現しようと思うと、 VCL表現力の低さにより地獄を見ることになるので、得られるベネフィット相談しながらこのあたりはやっていくことになる。

2021-04-27

カスタマイズ

Emacsカスタマイズにハマると幾らでも時間が消えていくと言われていたが、私はC言語でタブ幅の設定をするくらいだった。

Strutsの開発でTomcatプラグインが要ると書いてあったのでEclipseインストールするとか、会社の人からメールで送られたVimの設定をそのままペーストするとかくらいで積極的カスタマイズすることは無く。

IntelliJVisual Studio Codeの無数の拡張機能にも興味が無い。

シェル設定ファイルを頑張るのは時間無駄!という主張に共感したわけでもなく、普通に関心が無かった。

1990年代からコンピューターを使っているにもかかわらず……

しか2021年4月

急に凝り出した。「Emacs Lispっていうプログラミング言語でいろいろできるのか」「Visual Studio Codeマーケットプレイスには同じファイル対象にした拡張がいろいろあるな」と、今更。

なぜ。

でもまあ、設定にハマると際限無いのは実感できた。時間無駄っていう主張の意味も分かった。

2021-03-15

lispメリット

2021-02-20

COCOAの開発でXamarin使ってるっていうのがすごく不思議だったんだよね

あいうさ、共通フレームワークで作ってどっちでも動きますっていうのは

っていうときにやるもんじゃん。交通費精算とかさー、書籍の貸し出し管理とかさー。そういうのならわかるよ。

でもCOCOAはさ、

全然共通フレームワークを使う」前提を満たしてないじゃん。ネイティブアプリを2本作れやボケ

案の定フレームワーク由来の設定ファイル消えるバグとか産んでますよ。馬鹿じゃね。

2021-02-18

anond:20210217145745

デフォルトだとdotfilesはユーザーフォルダにつくられるから、頻繁に編集する人には有用なんだろう

あとは稀にAppData内に編集したくなる類の設定ファイルつくるツールがある

2021-01-25

[]

クリーンインストールからの構築

いままでのWindowsインストール人生の中で一番スマートに推移したのではないだろか?今回マザボなどを換装すると同時にM.2採用してみた関係上、クリーンインストールした。メディア光ディスク普通もっとメディアによるインストールって遅い印象だが結構苦にならなかった。WiFiモジュールが内蔵で、しかWiFiルーターのある部屋での作業だったから、ルーターWBS(?)ボタンを押すことでパソコンネット接続状態になった。これは楽だ。普通Winアップデートだのマザボ付属ドライバーなどのインストールが終わってからやっとこさLAN接続できて、さらにいろいろやってWi-Fiが。。。。って感じだが、インストール作業中に接続したのは びっくらこいた。WBSだったっけ?ワールドビジネスサテライト

チョコ便利!

アプリプログラム)のインストールほとんど一気呵成にchocolatey. Microsoft 365のサブスクラバーなのでそれは個別インストールGoogle-backup-and-syncだけはチョコで何度やってもうまくいかなかった。なぜだ?

WSLもできた

リナックスというかUbuntuね。これも順調。ただ、最初ドットがついた設定ファイルたちをコピーする気力はなかった。今週末先送り。

ブルートゥースのおかげかわからんけど

テレビモニター代わりにテレビ前のホットカーペットに座って作業できるように!これはLGTM. (looks good 2 me) テレビの前にリクライニングシートが欲しい。もしくはひざの上にのせる板付きクッション欲しい。暇さえあればパソコンいじりたい。背中に背負いたい。自宅の要所要所にモニターを置いといて、気分がのったら背中から降ろしてプログラミングとか行いたい。寸暇を惜しんでPCでアレしたい。司鯛。

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