「デプロイ」を含む日記 RSS

はてなキーワード: デプロイとは

2022-05-05

anond:20220504211823

まあちょっとしたWEBアプリ作るのも一昔前ならPHPでチョロチョロっと書いてレンタルサーバーにアップして済ませてたのが

今はgitからクローンしてバックエンドはLaravelでフロントVue.jsクラウドデプロイとかっていう我々アマチュアのおじいちゃんからすると趣味の枠を超えたことをやってるなと思うね

まあ実務で使える知識を覚えようとそうなっちゃうんだろうけど

開発環境の構築とサーバー知識がネックになって初学者がどんどん挫折するのを見てるので、もうちょい敷居を下げられないかとは思うんだよな

2022-05-03

[]2022年4月はてブあとで読むトップ30リスト

はてブホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ

590あとで/4204users 【詳しすぎる2週間】親の死亡後にまずやること(行動チェックリスト付) | まごころ相続コンシェルジュ

291あとで/1560users Google製のJavaScript教育ツール「Grasshopper」は基礎から学べて初心者に優しい!【どれ使う?プログラミング教育ツール】 | 窓の杜

272あとで/1859users 無料コーディング練習所 | 未経験からWebデザイナーへ!

220あとで/1327users 【翻訳Googleエンジニアソフトウェア開発する時に必ず書くドキュメント「Design Docs at Google」 - BppLOG

201あとで/1017users 30 分でわかる!アルゴリズムの基本 | E869120 | SpeakerDeck

191あとで/1365users Wi-Fiトラブル解決に便利! Windowsの隠れ便利機能Wlan Report」を活用しよう【イニシャルB】 | INTERNET Watch

175あとで/888users Web開発者もっと安全ウェブサイトの作り方」を読むべき - Flatt Security Blog

171あとで/2593users (追記あり) 10億円資産ができたときに知っておいたほうがいいこと | anond.hatelabo.jp

164あとで/849users AWS初心者向けの教材まとめ、AWS日本法人が公開 | ITMedia

162あとで/1231users 【試し読み】書店員さんから反響! 精神疾患を抱えた妻の介護仕事…約20年にわたる苦悩の日々を綴った傑作ルポ『妻はサバイバー』|朝日新聞出版さんぽ|note

159あとで/935users 機械学習が独学できる日本語Youtube難易度別まとめ - Qiita

152あとで/961users 8時間を0.01秒に短縮 「アルゴリズムの素晴らしさが2分で分かる動画」が今すぐ勉強したくなる分かりやすさ | ねとらぼ

142あとで/889users 文春オンライン記事分析を支える爆速ダッシュボードを作るまで|Shota Tajima|note

141あとで/2006users さよなら絵梨 - 藤本タツキ | 少年ジャンプ+

140あとで/1138users 新電力中の人です。すべてをお話します | anond.hatelabo.jp

136あとで/1094users 『ゴールデンカムイ』全話無料! | ヤンジャン!

135あとで/780users Docker創始者らが開発、ビルドテストデプロイ自動化ポータブルにするツール「Dagger」登場。そのままローカルでもGitHubでもCircleCIでも実行可能に | Publickey

132あとで/575users フロントエンドエンジニアが知るべきキャッシュ理解する | カーーズ | Zenn

132あとで/1232users みんなが知ってる『ちょっとのコツでめっちゃ美味しくなる、楽になる』みたいなの教えて→全然知らなかった有益情報が集まる | Togetter

131あとで/679users 【個人開発】正規表現を学ぶ狩りに出ませんか?モンスターを倒しながら正規表現が学べるゲームRegex Hunting」を作りました - Qiita

124あとで/1217users 先輩に「何かタメになる話してくださいよ〜」と無茶振りしたら『Language Reactor』という2言語字幕を同時表示できるChrome拡張機能を教えてもらった | Togetter

124あとで/1254users 育休中に相方がめちゃくちゃ売れた|酒寄さん|note

120あとで/1114users Google Analytics(UA)が使えなくなるのはどのくらいヤバくて、いつまでに何をしたら良いのかの話。 - フジイユウジ::ドットネット

120あとで/598users 電子情報学特論:Chromiumアーキテクチャを解き明かす | Kentaro Hara | Google Slides

119あとで/1242users 僕がたどり着いた最強パリパリチキンの焼き方→上手に焼くポイントも「鶏肉好きとしては是非とも取り入れたい」「最高のライフハック」 | Togetter

118あとで/866users 「全クリエイターに広まってほしい」文化庁質問に答えるだけで『著作権契約書』が作れる超便利なツールを作っている | Togetter

116あとで/897users ちょっと触ったら休日が丸2日消失した 個人2022年ベストゲーム「TUNIC」を全力で推したい | ねとらぼ

115あとで/798users 結局UMLとかシーケンス図とかAWSの図とかどれで描くと良いのよ?と思ったとき選択肢 - Qiita

112あとで/494users 『良いコード/悪いコードで学ぶ設計入門 』を出版します|ミノ駆動note

109あとで/522users 予防に勝る防御なし - 堅牢コードを導く様々な設計のヒント / Growing Reliable Code PHPerKaigi 2022

109あとで/1047users (続き)10億円資産ができたときに知っておいたほうがいいこと | anond.hatelabo.jp

はてブではあまり見かけなかったタイプの商用っぽいけど大手メディアじゃなさそうなサイトが上位に入った

2022-04-03

SPAコストが高いっていうけどコンテナインフラも同じだよな

コンテナって段階的に使うことはできなくて、運用とかデプロイ周りのコンポーネントを全て書き換えないといけないんだよな。技術力がないと必ず詰む。スケーリング再現性メリットがあるのはわかるが犠牲が多すぎる。俺は昔からコンテナインフラには懐疑的だったよ。

2022-03-15

anond:20220315194006

ですよね

いざとなったらレビューすっ飛ばしデプロイしている

自信ある人しかやっちゃダメなやつ

2022-03-08

AWS大先生質問なんだけど

インフラほとんど未経験

転職先がどうやらKubernetes構成管理してる会社で俺もその管理に関わる立場になるっぽいのよね

で、正式入社までの間にAWSのEKSにKubernetesで構築したWebアプリデプロイして軽くロードバランサ設定とかそういうの実際に触ってデプロイしながら勉強したいと思うんだけど、

ただそもそも大規模システム向けなサービスだしこれ金額面とか大丈夫かなって心配してる

想定はnuxtサーバ+バックエンドサーバ+DBサーバ適当アプリ作ってバックエンドサーバ辺りを分散構成かにしようかなと思ってる

実際の運用目的じゃないから使わないときはすぐ消すしそんな超スペックみたいな構成じゃないと思うけど、個人ポケットマネー(できれば1万円以内とか)とかでも行えるものかね?

2022-03-06

anond:20220306144905

ありがとう勉強になりました。

特にステートレスとモノシリックのあたり。

デプロイの際、どうしてもコンピューティングリソースベースで考えてしまうんだけど、この考えもいずれ古くなっていくのかな。

今のところはリソースは有限かつ課金制という前提でほとんどのクラウドは動いているけれども。

リソースをほぼ意識しないクラウドゲーミングの世界なんかに近いのかな。

先進的な考え方だから注視はしていきたいと思います

anond:20220306143946

サーバーレスビジネスロジックが分離されててスケーラブルだし

場所によらずデプロイできるからグローバルなサービスにあってるよね

リソースリッチ現代ステートレスアーキテクチャ

メンテナンス性に諸々優れてるというのは関数型プログラミングパラダイム(またはUnix哲学)で

我々エンジニア学習したことだしね。伸びると思うよサーバーレス

ただエコシステムや周辺の状況が発展途上だしサービスロジックによってはモノリシックな方が

あってるものもあるからケースバイケースでしょ

2022-03-03

クラウドに詳しい人に質問なんだが

当方Webアプリエンジニアで、転職先はアプリに加えてある程度インフラも触らないといけない会社なんだけど、

自主的勉強として

Terraform + Kubernetes +grpc(grpc-web) + nuxt.js簡単Webサービス作って

コンテナ環境AWSデプロイ、みたいなのって入社までの1ヶ月くらいで完了できる内容だと思う?

経験的にアプリレイヤはわかるけど↑みたいなコンテナ構築みたいなのはあんまりやったことない感じ

2022-02-27

個人ができるロシアへの制裁を1つ思いついた

2014年出来事だが、自殺方法に関するロシア語文章Github上にアップロードされたことにより、ロシア規制当局が、ロシアからGithubへのアクセスブロックする命令を出した。

https://ascii.jp/elem/000/000/959/959163/

https://jp.techcrunch.com/2014/12/04/20141203github-russia/

これは経済的損失が大きいと考えられる。

その文章リンクは(内容的に不適切なので)ここには貼らないが、上の記事の中にリンクがあるので、気になる人は自己責任翻訳してほしい。

私は機械翻訳したが、正直なぜこの文章ロシアにとってNGなのかわからない。恐らくロシア国民には分かる皮肉が入っているのだろうと思う。

この文章を他のサービスに貼り、ロシア当局ブロック命令を出すことで、制裁につながらないだろうか。

AWSにほぼ0円でデプロイするスクリプトを作ろうかと思ったが、そもそもロシアAWS使えないようだった。

ロシア IaaS」で検索すると、いくつかシステムインフラサービスがヒットするので、それらを検討中

かに影響が大きそうなサービスあれば、教えてほしい。

2022-02-22

WEB系のエンジニアって今の仕事が窮屈じゃないんだろうか?

かく言う、自分も俗に言うWEBエンジニア

この業界が息苦しいなと感じているものの、この業界に居続けている

トレンドを追うと、高速化効率化みたいな内容しか出てこない。

自動デプロイだの、描画速度の向上だの、テスト自動化だの、新しいAWSサービスだの…

からサービスは作れるし、外部サービス連携APIを見ればプレーンで書ける。

VPSみたいにサーバー用してもらえれば、プレーン運用も出来る。

でも、プレーンで描くと「車輪の再発明」だの「再利用出来ない」って言われる(幻聴かもしれんが…)

いかシェア率が高いメジャーライブラリ方法を使って開発する事ばかり

フロント周りもそう

この世界に入った時は、色々華々しい事ができるって思っていた

実際は、開発環境やらモダンな開発手法やらごった煮なお作法勉強しないと「トレンドを追え」と鼻で笑われる

フレームワークやらECMAScriptを使わずプレーンで描いたら白い目で見られる。

そこまで使いこなせて初めて新しい技術を触る権利がある位面倒くさい

追ったら追ったで、「これ今すぐ使う必要なくね?」ってなって勉強の意義を見出せなくなる

今の自分が、コピペで開発で満足していた過去自分を見たら、自分説教してくれた先輩のように説教をするだろう

ブログ鵜呑みにするな、ドキュメントを見ろ」「コードコピペすんな、書け」「闇雲に手を加えんなログを読め」ってね。

ただ、あの頃みたいに、とりあえず作ってブラッシュアップして行こうっていう気持ちが今もあればまた違ったのかもしれない

プログラム所詮道具なのに、道具の手入ればかり勉強している気がして何か窮屈だなって思う

だけど、その思考で数年やって来たからこの思考から抜け出せない。

プログラムでモノを作るってもっと自由で良かったはずなんだがな…

結局、自分の中で答えが見出せなくて、WEBから離れる事にした

2022-02-13

anond:20220212154229

それはできる限りやろうとしていて、それゆえ今のデジタル社会が出来上がっているのではないか

IDEの高機能っぷり。コーディング自動デプロイ自動テストリリース

といったCI/CD、DevOpsもそんなイメージで作られている。

それを使いこなすための知識だけでいっぱいいっぱいになってる気もする。

ラプラスの悪魔パラドックスみたいだ。

アプリ開発したこといから、そんなにわかんないんだけどね。

2022-02-02

anond:20220202191208

ちょっと勘違いしている。一度デプロイしたものはそのままだが、脆弱性が見つかったら新しいコントラクトに移行することができる。だから資金をずっとそこに置いておかなければならないということは無い。また、プログラムは丸見えというのはいい部分も悪い部分もあり、一概にそれがダメということは無い。また、厳密にはコントラクト脆弱性があり大規模な資金流出があったとしても、参加者合意の元覆すことも理屈では可能。The DAO事件がその例。ただし、Code is Low原則からズレた行為であり、原理主義から批判されている。

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

2022-01-11

Javaデプロイなんだけど相談に乗ってください

未だに warデプロイするのはなんでなんですか?

.java ファイルコンパイルして .class を配布じゃダメなんですか?

2021-12-28

プログラマとしての失敗

当初はWeb制作Javaパッケージソフトを動かせるようにということだったが、その後、そのパッケージで扱えない内容をPHPで開発することになった。

しかし、そのパッケージPHPとの共存を前提にしておらず、ライブラリの競合でなかなか動かせなかった。

それほど有名ではないパッケージソフト資料も少なく、社内に聞いてもあまり回答してもらえなかった。

頑張って動かしたと思ったが、デプロイ時にうまく動かず、障害が発生してしまった。

プログラマ経験初期の頃で自分経験が不足していたことも大きいが、早めにできないと言って声を上げるべきだった。

全体的にプロジェクトマネジメント機能しておらず、ただスケジュールを急かされる中で間に合わせようとして失敗した。

上司相談たかったが、打ち合わせ等でいないことが多かった。その後、すぐに上司転職してしまった。転職活動もあって、いないことが多かったのかもしれない。

プログラマ経験の中で最悪の失敗である

2021-12-21

anond:20211221122421

執行する人のボタンが3つだかあるんだよね

思ったんだけど、日常責任を問われると困る行為にも3つぐらいボタンほしい気がする

2人で同時にキーを回すみたいなの

デプロイするとかサーバーリセットするときは3つボタンがあって、3人いないと実行できないの

3つのボタンのうち1つが有効なんだけど、どれが有効なのかはランダムで変わるので分からない

ログも残さな

2021-10-15

日本全体の技術レベルが低い

最近、開発業務していて特に思うんだけど

とにかく全体的な技術レベルがどんどん低くなっていてヤバイ

具体的にどの分野が、とかどのレベルまで、というのはなかなか伝えにくいんだけど

「そんなことしたら将来的に破綻するでしょ?」

っていう指摘をすることが増えている

例えば接続が切れたときに再接続する処理を無限ループの中に普通に書いてたりして

スリープを入れてるならまだマシで中にはスリープとか待機せずに接続処理が始まるようなコードがある

当たり前だけどそんなものが巷に出回ると繋がらなくなったら輻輳しまくるので絶対にやめろと言うけど

テストの時は普通に接続できちゃうからパスしてデプロイされてるのも結構あると思う

サーバー側の設定とかも同じようなもの結構あって

「それって異常のときに困るよね?」

っていうところまで思慮が足りてない

今回のドコモの原因は分からんけど似たようなことはこれからも起きると思う

とにかくレベルが下がっててホント怖い

2021-10-14

文字多い

IT系なんだけど、やたら横文字というか社内用語多い気がする。

いまの会社15年位在籍してるんだけど入社当初聞き慣れず、むしろ嫌悪感すらあった言葉を今、普通に使ってる。

コミットアジェンダコンセンサス、アグリー、ファシリ、プライオリティアウトプット

コンテキストプロコンシェアドライバハンドリングリソース、オーサライズ、フィックス、

アサインジョイン、エビデンスリスケスクラッチデプロイペンディング、アペンディクス、

オーナーレイヤーロンチスキーム、ネゴ、アドホックショットフィードバックメンバーetc

呪文かよ。

染まっちまったな、俺も。比較ホワイトなので辞める決心が起きない。

でも、毎晩このままでいいのか、って自問自答。

2021-08-21

デプロイ王子守護霊です

みなさん、COCOAのことは覚えていますでしょうか。

2021-07-13

node_modulesのサイズ狂気の沙汰

npm install firebase しただけでnode_modulesが200M近い容量に膨れ上がるのどうにかならんの?

俺はHello.World.をfirebase hostingにデプロイしたいだけなのに。

2021-07-09

anond:20210709214950

ヒエッ、本職きたよ。ヌボボ

ちなみに医学部にいった友人の何人がむしろテック系に流れてきているという事情がある。

そこんとこ詳しく。メタップスとか?

東大卒だったら、言葉を正しく使え!

Waf なんて書くな! WAF とかけ!

Pub/Sub とか

うっせーな。クラウドベンダー独自 API なんか使いたくねーんだよ。オラクルじゃあるまいし。

DCL、DMLDDLといった用語を知っていることをひけらかしたかったのかもしれない

まぁ、それは認める。でもさ、select や create とかのDML/DDLCRUD と同じだけと、DCL なんて権限を発行できるりょういきにトーシロを突っ込むわけにいかないだろ。何も考えずに GRANT TO なんてプロダクション環境で発行されて日には、権限消失されたら永遠にデータアクセスできなくなるかもよ?

現場に放り込まれても10年ぐらいかかる。というより、フロントからバックからレイヤからモバイルまでやることはもはや現実的ではない。

そりゃそうだけど、フロントエンドは移り変わりが激しいじゃないですか。ほんの数年前までは Flash と DoJa のアプリを作ることがフロントエンド開発者でしたよ?一方データベースや OS の方は、ここ三十年ぐらい UnixRDB鉄板だった書ないすか。低レイヤだっていうけど、IoT なんかで C言語開発者バリバリっすよ。例えば、クラウドフレアなんか CDN の再発明をしてますけど、サーバーラックを見る限りだと差がついているのは低レイヤ根本技術改善であって、私はそこにプロフェッショナル性を見出しますがね。

C言語ができないのに「おそらく QUIC か MQTT 」とか分かってない英単語文字を羅列するのは厨ニ病すぎます

わかっていないのはテメーの方だ。今日オーバーフロー問題を抱えている C/C++サーバーの開発をしようとするのが危険なのは承知しろよ。パフォーマンス必要とするなら Rust、または GC があるけど Go言語を使って実装すべきだろ。高学歴なのは結構だけどは、現実は見えてないのか?いい加減にしろ

片手間でできません。インフラエンジニアに触らせます

そうだね~。卓越したインフラエンジニアがすぐに手に入るなら、問題ないだろうけどさ、ベンチャーや硬直化した雇用形態我が国で有能なインフラエンジニアをすぐに採用できるかよ。何年前の知識で戦っているの?時代は DevOps なんですよ。必要とあらば、すぐ学んで、応用して、デプロイできるのに「インフラエンジニア採用から始める」なんて、ヨーロッパが衰退する理由もよくわかるよ。プププ。

NextSSRまで踏み込む結構

誰が NextSSR なんてするか!あれは SEO必要場合に限る。そもそも SSR なんて危険からまともなエンジニアだったらしないだろ。問題になってないだけで、本当のブラウザクローラが見える内容が違うなんてスパム認定されてもおかしくないんだ。クローラインデックスされるページで SPA をやろうとするやつはセンスないで。

MyISAMInnoDBに切り替えるなんてことしているところは無い。万にひとつあったとしても、大事で、それだけで数ヶ月のものなので、この付け焼き刃の知識の人が触る機会はない。

すいませんでした。本当にすいません。

Kafkaを触ったとかいているが、Kafkaはサーバで使ったのかな?どういう利用シーンかというと膨大なログ収集等で使うのだが(ただのNoSQLではない)、Zookkeeperで調停させて、topic数とか調整するんだけど、わかってます

ん? AWS SQS だとパフォーマンス問題があることしたいから Kafka を使いたいのよ。確かに Zookeeper のことは詳しくないよ。だけど、AWS MSK 使うんで。PaaS というもんがあるので、だめなん?ログ収集は GKE みたいに ログに出したら Fluentd収集してくれる時代になんでグチグチ言われないといけないの?

Redisちゃんと使えてる?pub/subとか分かってないと思う(普通に理解する必要あんまない)

ハア?インメモリデータベースに信頼するほどヤワじゃないから。Redis なんて飛んでなんぼ。だから Kafka のようなストレージに保存されるメッセージキューを利用したいの。

code deploy

これないと、CI の責務が大きくなるじゃん。ほんでもって、ArgoCD なんて Kubernetes で展開したら運用までしないといけないじゃん。メンドクサ。

アメリカ事情は知らないはずなので知らないことは書かないようにしましょう。

いや、J1ビザをとってアメリカ留学したことあるよ。あと、「世界もっとも強力な9のアルゴリズム」「CleanCoder」「戦うプログラマー」 の本に書いてあるじゃん馬鹿にしてるのか?

 なぜ、ヨーロッパ人が避けるかといと「やる気がないから」です。以上

SAPアマデウスITとか強いじゃん。うそつき

https://anond.hatelabo.jp/20210708205945

=====

東大卒ヨーロッパエンジニアやっている人から解説しよう。(ちなみに医学部防衛医大に補欠合格していた)

エンジニアになるより医者やっていたほうが(国内で頑張る分には)絶対いいと思う

ちなみに医学部にいった友人の何人がむしろテック系に流れてきているという事情がある。

厨ニが溢れているので、しっかり解説してあげます

おそらく、増田はたしかに昔からプログラミングをやっていたと思う。頭もいいんだろう。厨ニが溢れていて気持ちが悪い。

エンジニア厨ニ病マウント取っていいていい時代でもないです。明らかにマウント取りたくてウズウズしすぎて、大した知識がないのに、

表面的な知識を羅列しているところがあったので突っ込んでいく。

~~誰にやらせてもデータベースにクソなDCLを飛ばせないから。逆に、データベースを触れることができるプログラマーリスク責任が大きいから、給料が高いのだよ

ー>そんなことない。フロントも色々やらないといけないが、バックエンドに比べて経験年数がひくい人も流れ込んできているので、バックエンドの人に比べて

できる領域が狭いので給与が低い、またおそらくDCL、DMLDDLといった用語を知っていることをひけらかしたかったのかもしれないが、全くどうでもいいです。

~~君はソフトウェアエンジニアになりたいのだろ?世の中は分業で成り立っているのだから、全部やろうとするやつはアホだよ

=>全部できようとして、破綻しているのでブーメランですよ。あなたの想定している、こんなフルスタックは成り立たない。

現場に放り込まれても10年ぐらいかかる。というより、フロントからバックからレイヤからモバイルまでやることはもはや現実的ではない。

~~おそらく QUIC か MQTT あたりだろ?逆にいえば、それが実装できたら他社と差のつけられるプロダクトだったはずだ。つまり会社利益の源泉であった部分をみすみす実装できないようでは、そこらへんの専門卒以下だぞ。

=>QUICとかマイナープロトコルを話すよりはちょっと変化球のあるプロトコルでいけばWebsocketぐらに抑えておきましょう。低レイヤーの話はわたしもわかりませんが、C言語ができないのに「おそらく QUIC か MQTT 」とか分かってない英単語文字を羅列するのは厨ニ病すぎます

~~プログラマーに徹するつもりだろうが、ツヨツヨエンジニアデプロイした経験から逆算してコード設計・開発をやるのだぞ。そうなると、CDN, DNS, WAF, S3, ログの出し方、メトリックス、異常検知、アラートを把握する必要があるのだぞ。そういうのを知るためには、ポートフォリオAWS GCP Azure といったクラウド経験を書くべきだと思うのだが、なぜしない?

=>自分cloudfrontやWafを触ったことがありますが、かなりのインフラエンジニアにならないかぎり、ここ触りません。cdnは影響範囲が大きいし設定に時間が掛かったりします。片手間でできません。インフラエンジニアに触らせます。異常検知、アラートといったものは、実は結構時間がかかるので、強いかどうかではなく責務の分割からインフラに任せます。知らないことは知らないって書きましょう

本当に医学生ならここ数年の技術についてこの指摘ができる程詳しいわけないし少なくとも10年位は業界にいないとこういう感覚は身に付かない。 」

~~たしかおかしいよな。Kubernetes や Terraform を弄って、CIGitHub Actions、CD には AWS CodeDeploy を使って、ブログは Jekyll で静的サイトジェネレータを使いつつ、自前のサービスを立ち上げるために Rails, Next, React, PostgreSQL, Redis, Kafka, Elasticsearch, S3 の勉強をしつつ、スマホ環境のために KotlinSwift を触れているなんて変だよな。そういえば、Docker が来るまでは Vagrant環境をつくっていたのも忘れてたよ。あと Rust を今年に学ぶ言語にするなんて、受験生にあるまじき行為だよな。うん。

=>こんなにあれこれ、やっている時間はないでしょう。趣味サイト製作でやるにしても絶対できてない。kubernetesを使っただけで時間切れになる。Kafkaを触ったとかいているが、Kafkaはサーバで使ったのかな?どういう利用シーンかというと膨大なログ収集等で使うのだが(ただのNoSQLではない)、Zookkeeperで調停させて、topic数とか調整するんだけど、わかってます?ElasticSearchだけ書いてたらまぁあるかなと思うけど。Redisちゃんと使えてる?pub/subとか分かってないと思う(普通に理解する必要あんまない)

それでkotlinなんて触ってる時間なんて絶対にないし、Rustを更に付け焼き刃に付け焼き刃している時間なんてぜええええたいにない。やることが絞り込めてない。無意味マウント取りたいだけ。なんとなく書いているcode deployなんて、それだけで使いこなすのが大変なれべる。

ci/cdのうちciだけかたっているならわかるがcdとなるとかなり時間がかかる

~~ストレージエンジンが切り替わるときカオスな目にあったけどさ

=>MyISAMInnoDBに切り替えるなんてことしているところは無い。万にひとつあったとしても、大事で、それだけで数ヶ月のものなので、この付け焼き刃の知識の人が触る機会はない。

~~TypeScriptNext と React を書く。もちろん JavaScript は ES2020 あたりまでは説明可能

=>ES2015以降の差分は微々たるもので、どうでもいいです。ES2018ぐらいの現実的数字にしてたらばれなかったのにね。

NextSSRまで踏み込む結構フロントのことをキャッチアップするだけでかなり厳しいと思いますが、できているのかな?

=====

~~アメリカでも「テック系はハードから避ける」

ー>アメリカ事情は知らないはずなので知らないことは書かないようにしましょう。

ー>ヨーロッパでは白人様はHRとかマーケやってます移民にたよってますロシアウクライナインドパキスタンなど

  なぜ、ヨーロッパ人が避けるかといと「やる気がないから」です。以上

※ちなみに防衛医大の補欠合格東大に入る人なら大体受かると思う

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