「Git」を含む日記 RSS

はてなキーワード: Gitとは

2022-05-10

エクスプローラgitが入ればいい

Tortoiseみたいなゴミじゃなくてまともなやつな

gitじゃ駄目なんだよgitじゃ

バカには使えないか

俺もバカから

2022-05-07

従業員50人ほどの中小IT企業のFLOSS活用事例 n = 1

弊社ではその設立当初、というよりも創業者(=私)が個人事業主だった頃から業務にFLOSSを多用しています
今回その事例を情報共有するためにエントリ作成いたしました。

従業員50人ほど(学生アルバイト含む)の会社です。ちなみにかなりボカして書きます

社内文書ODF

弊社では社内文書SDGs観点からペーパーレスに努めており……と表現すると些か格好付けすぎなので正直に言えば個人事業主時代印刷機複合機ランニングコストバカにならなかったので物理ペーパーへ出力するのを控えていた運用がそのまま法人化されても続いているだけです。

社内文書として用いられる文書フォーマットODF形式統一している……というかコレもまた個人事業主時代OpenOffice活用しており、現在社内で使われている主なオフィススイートLibreOfficeとなっています
注意点としては弊社がルールとして定めているのはODFを用いることでありLibreOfficeの利用を強制しているわけではないという点です。
従業員の中にはLibreOfficeを常用せず、AbiWordやGnumericを普段使いしている者も居ます
弊社は社外とオフィス文書ファイルをやり取りすることが一切なく、オフィス文書ファイル表現するには正しくないですが社外とはPDFをやり取りするくらいなので何か問題が起きたことが今まで特にないです。

えんたぁぷらいず……

ただ1つ問題があり、弊社はこれまでLibreOffice無償活用させて頂いており、これまでの感謝を示すためLibreOffice Enterpriseへの移行を考えているもの日本国内LibreOffice Enterpriseを利用するための情報が一切なく困り果てています
最悪、海外企業を頼る方法もありますサポート時間の都合などがあるため可能ならば国内で探したいと考えています。どうにかならないものですかね?
社内では「むしろウチがやったら?」なんて声もチラホラ聞こえますが……。

ちなみに社内デファクトスタンダードフォントはNoto Sans Japaneseです。一部でTakao(IPA)が使われています

OSの縛りを設けていない

弊社ではFLOSSを活用しているせいもあって特にOSの縛りを設けていません。何なら経理担当Chromebook使ってます
社内のOSシェアはChromeOSを含めたLinuxディストリビューションが5割、macOSが2割、残りがWindowsとその他です。

気になるであろう開発環境についてですが、Dockerを用いて開発環境統一化を計っており、その時々に応じてDockerコンテナを切り替えて開発しています
Dockerを用いているせいもありLinuxディストリビューションの社内OSシェアが高くなっているのです。
プライベート従業員は様々なOS選択しているようです。ゲームとかVR趣味であるならばWindowsしか選択肢ないでしょうしね。

ちなみに業務用のPCBYODで購入補助あります
結局は従業員現物給与として課税されてしまうだけなので「いくらでも良いけど高すぎるの買うと年収増えすぎて痛い目みるよ?」とは助言してます
会社はまとまったお金を出しているに過ぎないのでメリットデメリットがありますよね。

GNUプロジェクトソフトウェアは無申請で利用可

いちいち申請出す方もチェックする方も面倒なのでGNUプロジェクトソフトウェアは無申請で利用可としています
ただし制限公式リポジトリまたは弊社が安全だと判断しているリポジトリで配布しているバイナリのみという条件が付きます

本番環境ホスト先は色々

どこの会社もそうでしょうけれどもAWSAzureGCPなどたいてい大手に置いてますね、予算の都合もあるけれど。

デザイナーは主にWindowsを使っている

これは弊社が強制しているわけではなく、弊社デザイナーの第1号従業員Windowsユーザであったので惰性のままWindowsとなっているだけであり、中にはMac仕事している従業員も居ますし、状況によってLinuxディストリビューション(主にUbuntu)上で仕事しているときもあります

Linux環境では苦手なIllustratorAI形式などはSVGラスタ画像に落とし込んでもらって開発者適用するという運用になっています
社内では特定環境依存するファイル形式はとことん嫌われる傾向にあります(妙な仕事が増えるから)。

みんなGitが使える

開発者から経理デザイナーに至るまで弊社従業員はみんなGitが使えます
ただし使えると言っても全員がCLIからコマンドを打てるわけでなくGUIクライアントから操作しか出来ない者も居ます
主に使われているGitGUIクライアントGitKrakenです。

入社時の受け入れ教育LibreOfficeGit指導をすることになっており、全従業員が浅くともGitとは何ぞや?を理解している状態にあります
ちなみにGitリポジトリは主にGitLabへ置いていてUltimateを契約させてもらってます

社内にセルフホストしているGitLabサーバもありますが、こっちは従業員個人開発しているものを投げているようですね。業務にあまり使われていません。緊急時バックアップと思われるものがちょこちょこありますが。

プロジェクト管理ツールはopenproject.org

プロジェクト管理ツールはいろいろと試したのですがOpenProjectへ落ち着きつつあります
プロジェクト管理ツールの選定は各プロジェクトマネージャへ任せているのですが、旧来からあるRedmine操作性が近い上にGitLabとの連携も容易でなかなか良いとのこと。

社内チャットは主にElement(Matrix)

他社とのやり取りにSlackやTeamsやZoomが出てくることもありますが、社内だけで完結する際はたいていElementが使われています
これは当時インターン生だった弊社の現従業員若者の熱意と共に持ち込み、サーバを与えたら喜々として運用をはじめたので、それをきっかけに便利だったからそのまま使わせてもらってます

ぶっちゃけて言えば私個人のこだわりはチャットにありません。従業員が楽しそうに使っていればそれで良いんじゃないかと。
IRCとか持ち出されたら「今どきそれはどうなの・・・まぁ良いけど」って言うかも知れませんが。

会計はFreee

会計はFreeeです。特にこだわりはありません。たまたまWebブラウザから使えたのでFreeeとなってます

弊社は95%リモートワーク

残り5%は主に私が出社しているからw
社内にサーバがあるので私以外も出社してくることはあります基本的コロナ禍以降は全従業員リモートワークです。
そもそもコロナ禍以前でもリモートワークしてた気がしなくもないのですが当時は3割4割くらいだったでしょうかね?週に何度か出社して来ないが自宅からdoneしてくる従業員が何名も居たので。
タイムカードもElementのbotへ投げると自動的に処理するようになってます……が、実際のところ最後の処理で私が大目時間を付けてます。打刻を忘れることもあるしね。少ないより良いやろw

結局、郵送物(今ならコロナワクチン関連とか)を処理する必要があったりなど誰かしら会社に人が居なければならず、自分でも忘れがちですが創業者なので私が会社に居るよってことで私だけがほぼ出社するという状況になってます
オフィス処分も一時期考えたのですが、増員への教育とか考えるとやっぱりオフィスあったほうが良いよなぁなんて思ってそのままです。もしかしたら引っ越しするかも?

1つだけ申し訳ないことがあって、コロナ禍の状況下でどうやって増員したら良いのか教育したら良いのか私の能力を超えていまして現在新規募集を停止中です。いやホント申し訳ない。
事業軌道に乗った以降は毎年最低1人は取ろうねと古株と話していたんですが、こうなっては無理だよねと苦笑しあってます
どうやって世間の同規模中小企業新人教育やってるのか解らなすぎる。会社に誰も居ないじゃんと。

上場する気も更々ないし無借金なので、のん気にこのままゆっくりと会社を維持していきたいなぁと思ってます
早くコロナ禍終わらんかなぁ……。

2022-05-05

anond:20220504211823

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

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

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

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

2022-04-29

anond:20220429094749

エンジニアと大雑把に括られてるけど、実際にやることはその中の職種によって凄まじく違うことに注意な。

やりたい事に近い事、お前さんのイメージするエンジニアに近い事をやるといい。

んで、こだわりないなら両方やっとけ。

基本情報なぞ簡単に取れる。取れなきゃ次は、アプリサービス作る過程で色々調べたりした経験に、ちょいと試験向けの勉強する程度で取れる。取っとけ。

アプリサービス作りは難しい。作ろうと思うだけでなく、実際に手を付けられる奴はそう多くない。サンプル通りでない物を自力で完成させられれば、エンジニアに十分向いてる。本当に難しいのは作ることではなく、その先の続けることの方ではあるんだが…。

で、だ。単に就職できればいいや止まりの話でなく、アプリサービスを作りたいという思いがあるのなら、何かを作ったり設計したり企画したりしたいという思いが自分自身の内にあるのなら、だ。

まず紙のノート買ってこい。これが何よりも大事。そして捨てるな、一生。

作りたい物の全体デザインを書いてみろ、その最初の数枚は絶対に捨てるな。残りも可能な限り捨てるな。

スケッチブックノート、中性紙で。無地が望ましいが近所での入手性も大事。人に見せることもあり得るのでA4以上、携帯したいとしてもB5以上。

リングでも綴じでもいいがルーズリーフを継ぎ足せるタイプは論外。紙を切り取るミシン目があるのも論外。後から整理しようとするな。余分なページを外そうとするな。丸ごと取っておくんだ。

筆記具はボールペンフリクション絶許。ホワイトダメ。消す時は横線で。消したという判断も、それを一旦は思いついたということも後から見れるように。

請けた仕事用とは絶対に共用するな。プロジェクトを離れる際に、機密漏洩防止のため捨てることになるからプロジェクトの成果の持ち主が本人なら知らぬ。

環境ノート絶対捨てない事を許さないのなら…電子データでもやむを得ないが、クラウドストレージ+バックアップガチガチに消えないように。そして跡を消さず、整理せず全て残すように。

お前さんの方向性次第では、本当に必要なのはDesign Docsのような電子データ文書かもしれない。それでも要所は同じ。

gitに突っ込む。横線で消すのではなく、git履歴比較できるデータ形式にしておく。履歴を後から整理しようとせず、ガチガチに消えないように全て残す。

グッドラック

2022-04-27

anond:20220427175508

そうだね。Instagramへのシェアボタンがあってもいいし。中国のwebio(?微博)へのリンクがあってもいい。

livedooramoebayahoo!ブログライバルからFacebook流れるように足を引っ張りあったのかもね。勝手妄想〜。)

Linkdinやgit hub, qiitaへのリンクがあってもよかったのに。

2022-04-21

よく使うgitコマンド

git branch --all

git switch

git switch -

git diff

git diff --cached

git cherry-pick

git reflog

git commit --amend

git add . -p

git pull

git show

git fetch && git merge origin/master

git merge

git merge --abort

git rebase -i HEAD^^^^^

git tag --delete

git tag -d

git log

git log --graph

git push

git push --force-with-lease

git push --force

git push --tags

git push --delete

git push --set-upstream

git status

2022-04-14

gitは罠」だなんてネタでもなんでもないからな

いまだにvss使ってる現場すらある

そういう低能を正しく切断処理できなかったからこの国は駄目になってしまった

2022-04-01

anond:20220401200632

ITシステム開発だと、例えばgitリポジトリ場所とかブランチ運用フローとかは書いてほしいけど、

コミットとかプッシュのやり方とかは別に書かなくてもいいな。

それが書いてないとコミットとかプッシュできないやつはダメでしょ

2022-03-27

anond:20220327195817

gitとかAWSとかあたりも同じような気持ち悪さを感じる

2022-03-16

githubgitプロトコルが使えなくなったのを踏み抜くの巻

大事でなくてよかったナリィ…

2022-03-04

おっちゃんエンジニア排除できない問題

2022-03-03

今日の午後はGITリポジトリ見ながらあの作業をした。本当はもっと完璧な一覧表じゃないとダメだけどまあええわ。こりゃ英和。どうでもよくなってきた。とにかくファイル光学ディスクに焼こう。焼くなんて面倒だ。21世紀も廿年も経過して焼きこ?紙に印刷して出すよりはましか

2022-02-20

回線工事しなくてもいいってやつ

別に5Gでなくて4G?でも繋がるの?

回線速度遅くても工事しないのは引越し時にも便利では

ゲームとかやらんし、動画も低品質でいいし、

もうgit cloneできればいいよ…

2022-02-15

gitファイル大文字文字の違いをcore.ignorecase=falseに設定してもうまく扱えない

大文字文字ファイル名変更だけを行ったコミットがrebaseできん

そもそもリーナスは何を考えて大文字文字区別をしないのを既定動作にしたのか、だれか教えてくれ

2022-02-07

大企業はいつになってもDXなんて無理

DXコンサル的なことをやってるがそろそろこの業界限界

そもそも大企業上層部はDXっていうのを買ってくればDXできると思ってる。

DXっていう製品が無いというのは理解しているんだが

DXっていう研修とかDXっていうコンサルを買ってくればDXできると思ってる。

これが中小企業ぐらいだったら鶴の一声でDXできるかもしれない。

ところが大企業っていうのは意思決定者が細分化されていることが多くて

社長が「DXするぞ!」って言っても実際に社長はDXの状況を年に1回ぐらいしか確認しないし

伝言リレー下部組織に伝わるうちに

「結局はこれだけやってりゃいいんでしょ?」

っていう謎理解だけで終わってしまう。

例えば、社内の会計システムエクセルよりダメダメな終わってるような会社(某大手通会社)でも

それを変えようとすると

「これで慣れてるから変えるな」

「新しいシステムを習熟する研修はどうする」

みたいな声を「忖度」してしまう。

これ、実際にはそういうこと言う人はほとんど居ないんだが

会計システム管轄している部署が実際に使う人達部署の上位組織にあたることはほとんど無いし

下手したらコストセンターの部長営業系の部長より立場が低い場合がある。

から売り上げが下がるような可能性を忖度して新しい社内システムなんて簡単には入らないし

入れるとしても無茶苦茶時間かけて旧来のシステムとの整合性とか気にしまくってから導入する。

そうすると現場の人からすると

「前のシステムでもいいなら前のシステムでいいでしょ」

ってなってほとんど使われないのが現状。

他にも何かしらDXしようとしても結局は上司意見忖度する。

パワポ資料やめてnotionにしましょうとかソースコードSubversionやめてGitしましょうとか

そういうことを「言うことが構造的に難しい」っていうのが根本的に問題

社長部長が「そういう声を拾うぞ!」とか言ってご意見箱的なのを用意したりもするんだが

結局そこに投稿されてる提案が良いのか悪いのか判断できないか無駄

必要なのはリーダーシップというある意味独裁的なやり方であって民主主義的なことをやってたら成功しない。

なのでDXを本気でやりたかったら上層部人間イケてるベンチャーで下っ端として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

2022-01-24

【令和最新版増田ライフハック

Google検索で「site:anond.hatelabo.jp」と幾つかのキーワードを入れて2018年以降でピックアップした。

2018-04-15 COMIC快楽天無修正合法的に閲覧する方法

anond:20180415014902

2018-07-05 増田lifehack50選

anond:20180705011010

(筆者注:元ネタ

2018-08-06 粉を持ち歩くには、どうしたら良い?(追記)

anond:20180806120235

2018-11-21 マニアック面白いSF教えて

anond:20181121140118

2018-12-22 冷凍してよかったもの2018

anond:20181222121438

2019-02-03 クソ簡単git説明をする

anond:20190203175803

2019-02-07 甘くなくて、カリカリ言わないおやつ

anond:20190207070211

2019-02-07 お前らみたいな化粧水使ってるアホにスキンケア教えてやるよ

anond:20190207135140

2019-02-12 あさってマンションを買う

anond:20190212091153

2019-02-22 平日の日中に男一人で楽しめることを知りたい

anond:20190222213414

2019-04-14 みんな眼鏡にどれくらいお金かけてるの

anond:20190414092612

2019-05-30 簡単初心者向けの資産形成 (長期投資)

anond:20190530215559

2019-06-01 ロードバイクに乗り始めて5年になる俺が断言する。

anond:20190601022419

2019-07-01 ダンボールを捨てるときは、貼ってあるシール類全部剥がしておけ

anond:20190701092741

2019-08-07 年間150回オーバー風俗行くワイが値段別で風俗の選び方をオススメ

anond:20190807014249

2019-10-30 貯金が底をついた。誰か助けてください。

anond:20191030194616

2019-11-16 エクスプローラ周り重い人向け覚書

anond:20191116220232

2020-01-02 (追記しました)もうすぐ30歳になるので15万〜20万で買えるもの教えて下

anond:20200102163416

2020-01-28 オタク特有の声の感じをなおしたい

anond:20200128093815

2020-01-23 【追記】頼むから障害者作業所商品買ってくれ

anond:20200123025202

2020-01-22 リングフィットアドベンチャーを2ヶ月やってみたデブのあれこれ

anond:20200122235134

2020-03-23 オススメベットが知りたい

anond:20200323211500

2020-03-28 引きこもるのに飽きてきたなら餃子を作れ!!今すぐにだ!!

anond:20200328190842

2020-03-31 QOLを上げるちょっとした食べ物メモ

anond:20200331111124

2020-05-25 普段使ってる便利なWebサービス教えて

anond:20200525021541

2020-05-28 資産5000万円を達成したので使い道教えてください

anond:20200528115619

2020-05-30 年収1000万のリアルを教えよう

anond:20200530164357

2020-07-02 目を使う趣味しかない

anond:20200702061339

2020-07-16 【追記青空文庫で読めるやつのオススメ教えて

anond:20200716151032

2020-08-13 どうやらミシンが売れているらしいので→追記しました→続編書きました

anond:20200813153635 

2020-09-02 チー牛だった自分イケメンになるためにした全部の作業

anond:20200902113316

2020-09-08 ケンタッキー初心者指南

anond:20200908192259 

2020-09-23 さっさと気付いた方が良い事

anond:20200923101921

2020-10-12 一人暮らし自炊パスタが最強

anond:20201012125859

2020-10-17 「車の維持費」の意味わかってない奴多すぎ(追記あり)

anond:20201017180336

2020-10-23 追記(10/24)ADHDだけど服をどうすればいいかからない助けて

anond:20201023204100

2020-10-26 ファミマ中の人ですが、今後もセブンイレブン詐欺方向で頑張るでしょう

anond:20201026165042

2020-11-24 Netflixブコメに救われた

anond:20201124175441

2020-11-25 書いたな、俺の前で、低温調理の話を!

anond:20201125213417

2020-11-29 投資の話が理解できない人との断絶がヤバイ 追記あり

anond:20201129045319

2020-12-16 人の家にあんまないけど自分ちにある調味料

anond:20201216122413

2020-12-19 スクワットしたら人生好転した話

anond:20201219220238

2021-01-01 追記:マッチングアプリで50人会って彼女できそう、なのにできてない

anond:20210101060523

2021-01-05 1年に100冊本を読むまでにやったこと(追記

anond:20210105024253

2021-01-14 沖縄県民の俺がおすすめする泡盛

anond:20210114003006

2021-01-14 耳が痛くならないイヤホン、あるいはヘッドホンマイク付きで)

anond:20210114234038

2021-02-07 2021年版・ド初心者向け仮想通貨投資の始め方

anond:20210207143934

2021-02-08 自分で高出力レーザー買って自家脱毛やってみた

anond:20210208163316

2021-02-23 取り返しのつかない我がエンジニア人生

anond:20210223235037

2021-03-13 30歳だが人生に飽きた

anond:20210313235019

2021-03-17 やおい小説読んでたらTOEIC900点いった

anond:20210317002946

2021-03-29 一番うまいレトルトカレー銀座カリーです。

anond:20210329103230

2021-03-30 筋トレなんてしなければよかった

anond:20210330045538 

2021-05-14 弱者男性だけど丁寧な暮らしをしてみた

anond:20210514235615

2021-06-02 仮想通貨バブルは終わるが、PCパーツ屋はグラボ闇市から抜け出せない

anond:20210602164233

2021-08-15 洪水被害にあったらやること

anond:20210815211223

2021-08-19 3万円でQOLあげたい

anond:20210819083427

2021-09-14 就職氷河期世代だが、癌になった。

anond:20210914162216

2021-09-20 ものすごくいい加減なディズニー映画史

anond:20210920161004

2021-09-26 【追記×2】少額だが株で(?)必ず成功する方法教える

anond:20210926075854

2021-11-23 乳児とパパのお出かけに便利なもの

anond:20211123155359

2021-12-10 夫に勧められてガンダムを見始めた

anond:20211210043823

2021-12-30 発信者開示、めっちゃ増えてるから気をつけたほうがいいよ

anond:20211230132738

2022-01-05 住宅ローンってQOL破壊的に激減させるんだな

anond:20220105113321

2022-01-06 住宅ローンQOLが瀑上がりした。

anond:20220106071937

2022-01-19

anond:20220119015800

元増田だけど、この増田すごい。結構俺を見抜いてる。

古い技術を使っていて、キャッチアップできてなさそうな予感がする

一人で開発してるようなので、プルリクベースのチーム開発できるか不安

これほんとそのとおりですわwww

フレームワークとか今はあれこれいっぱいありすぎるけど1つしか使いこなせてないし

gitも超基本的操作しかできないし、チーム開発でバージョン管理ソフト使ってたのってvisual source safeぐらいだし。

2021-12-24

とあるスタートアップが終わる時 (4)

前回: https://anond.hatelabo.jp/20211223003204

スーパーエンジニア様も期待通りにはいかず、細部の仕様も決めきれない、開発者も不慣れなフレームワーク四苦八苦

ということで進捗は芳しくなかった

(仕様に関してはそもそもコンセプトから決まってないかしょうがないが)

時間けが過ぎて、調達資金も目減りしていく

VCに何か言われたらしくCTOが段々イライラしてきたのが伝わってきた

新たに人員を増やす事になり、何人かフリーランスの人を入れた

その中にKさんと言う人がいた

CTOは「単金が安かったから、簡単仕事をお願いするつもりで呼んだ」と言っていた

その人はこの業界には珍しく50代くらいのオジサンだった

KさんCOBOL時代からプログラマーをやっていた人らしく

まりweb系の開発になれていないように思えた

git操作もおぼつかない

テキストエディタ秀丸エディタっていう変なやつ使っていた

正直この人は厳しいだろうな

そう思っていた

CTO自分も下に見ていたのは間違いないと思う

次: https://anond.hatelabo.jp/20211225003115

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