「リポジトリ」を含む日記 RSS

はてなキーワード: リポジトリとは

2022-10-17

anond:20221016033316

最近AUTOMATIONの人のリポジトリのissueで見たけど、モデルファイル起因でRCEできるようになってたらしいね

2022-08-02

anond:20220802000601

したがって、ネットワークアクセスできないなどの理由で中心リポジトリアクセスできない環境でも、履歴調査や変更の記録といったほとんどの作業を行うことができる。これが「分散型」と呼ばれる理由である

まあどのみちGitHub死ぬとその日一日休暇出されたりするんだけどな! ガハハ

[]Git

Git(ギット[2][3][4])は、プログラムソースコードなどの変更履歴を記録・追跡するための分散バージョン管理システムであるLinuxカーネルのソースコード管理に用いるためにリーナス・トーバルズによって開発され、それ以降ほかの多くのプロジェクト採用されている。Linuxカーネルのような巨大プロジェクトにも対応できるように、動作速度に重点が置かれている。現在メンテナは濱野純 (英語: Junio C Hamano) で、2005年7月から担当している。

Gitでは、各ユーザワーキングディレクトリに、全履歴を含んだリポジトリの完全な複製が作られる。したがって、ネットワークアクセスできないなどの理由で中心リポジトリアクセスできない環境でも、履歴調査や変更の記録といったほとんどの作業を行うことができる。これが「分散型」と呼ばれる理由である

2022-05-16

価値観アップグレードに失敗しました!

価値観アップグレードのためのリポジトリのいくつかが破損、または到達できません!

人生再起動して、価値観アップデートからやり直してください!

価値観が衝突しているため、削除できません!

価値観依存関係を修復してください!

価値観が古すぎます

ただちにアップグレードしてください!

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-04-25

anond:20220425193347

ならないんだよなあ。

そもそも数学プログラミングモチベーションが違うんだよね。数学における証明構成証明と非構成証明があるように、「手続き」というのは数学のごく一部でしかない。それに対して、プログラミングは「手続き」が全てだよね(って言うと関数型とかの人があれこれ言ってくるけど、関数型言語だって結局コンパイラ手続きに落とせる範囲のものしかない)。

機械学習については、論文書いてる奴も含めて大多数はプログラミング脳なので、最初からコードで発想してそれを論文にするために無理矢理数式で書いてるだけというものほとんど。無理矢理書いた後付けに過ぎないか意味不明ものも多いしコードに落とせないもの普通にある。だから数式は無視して著者のリポジトリにあるコードだけ見てればいいよ。実用観点ではコード公開されてない論文は全無視で何も問題ない。

2022-04-20

anond:20220420015209

Nix はいいぞ。

#!/usr/bin/env nix-shell

#!nix-shell -i "zsh" --pure -p zsh moreutils

# ... moreutils に含まれる ifne とか sponge とかのツールが使える.

パッケージマネージャ Nix のシェバンを使うと、

ツールインストールした上でスクリプトを実行する

...っていうのができる。

上記の例の "zsh" を、"make -f" とかすると Makefile になるし、リポジトリ nixpkgs に含まれファイルを渡す式のコマンドなら何でも使える。実行ファイルにしたスクリプトを走らせると、その場でインストールされてないツールインストールしてくれる。

ささっと書いたカジュアルスクリプトでも、将来、環境が変わっても使えてると嬉しい。本格的なプロジェクトを作ってパッケージマネージャリポジトリ登録するつもりはない、そんな場合に Nix のシェバ機能は役に立つ。

Nix 言語を使うと、かなり柔軟にインストール方法を作りこめる。シェバ機能を覚えておくだけでも効果が高いから、おすすめだよ。

2022-04-01

anond:20220401200632

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

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

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

2022-03-31

https://b.hatena.ne.jp/entry/s/zenn.dev/sesere/articles/c3917db32777af

文脈がよく分からないので、他での指摘と重複していると思うが、個人的に思ったこと。

文章MECEでないので「まあそういうことね」という話は措いておいて。

a. 日本語ウェブサイト記事本数で比較することはフェアではない

新しめの技術活用している人の情報収集の順番としては、エディタライブラリの当該部分のソースコードを読む、GitHubリポジトリがあるのであれば、そこのissuesで検索をかける、Google英語エラー文言等なので必然的英語になる)で検索する、Stack Overflow質問するという感じだと思うので、Qiitaでの出現数が減ることは仕方ないと思う。

ミクロで見ると、フロントエンド系の主要な論客Qiitaから離脱していることもある。

b. SPAという概念が古い

SSGの登場によってSPAネガな部分のほとんどは潰されていると思う。

SPA的な手法を使うのであれば、SSGにしろという指摘であれば、的を射ていると思う。

他にも色々と言いたいことはあるが「SPAのことを言ったら一斉に突っ込まれた」という事象観測できないので、とりあえず以上。

2022-03-30

anond:20220330193142

元増田です

なるほど、ありがとう

ソラミツのGitHubリポジトリがいくつかあったので見てみたよ、決済的な部分はイーサリアムポルカドットフォークっぽいね

こういう国際的な試みが、仲間外れなしにできると俺的には理想

今の日本電子カルテみたいに、SIerSaaSベンダーが各々アプリケーションを乱立させると局所最適になってエンドユーザー(この場合患者)にとってはあんまり便利にならないんだよね

公的な仕組みは国連みたいなでっかい組織体作ってガッとやったほうが面白くなるんだよなあ

議論に終始する可能性もあるけど、国ごとに達成できるかも不透明エネルギー政策掲げるよりよっぽど有意義だと思うんだよ

俺が急進的過ぎるのかな

2022-03-18

大学運動選手恋愛経験競技生活に及ぼす影響

恋愛経験の有無3群で比較したところ,有意には至らなかったが(χ2=4.01,df=2,p=.135),交際経験を有する者の約75%が,記録を伸ばしているし,いずれの群でも過半数以上が大学3年生以上で記録を伸ばしている.今回の調査対象者には競技レベルの差があることは否めないが,恋愛経験と成績向上には負の関連性はないし,恋愛肯定的効果示唆される.

交際期間の長さ3群で比較した.対象恋愛経験のある49名である.χ2検定の結果,5%水準で有意差が認められ(χ2=6.38,df=2,p=.041),長期間交際群の約8割は記録を向上させている.中期間では向上,低下が半数となっている.短期群13名でも記録低下させていた者は1名のみである.長期にわたる特定相手との交際のみならず,短い期間であっても,記録の向上とは関係なく,長期間の安定した恋愛経験は記録の向上に寄与することも考えられる.

我々のデータからは,大学運動選手恋愛競技マイナス要因ではなく,競技生活を充実させるプラスの要因になると言える.本論の副著者は,在学中も全日本トップレベル女性アスリートで4年生次に最高成績を収めている.彼女自身学生時代恋愛には肯定的であったし,「あくまでも競技生活第一優先事項という前提が不可欠で,恋愛関係競技生活の優先度が逆転してしまうと、やはり競技生活に悪影響を及ぼしかねなかった」と回想している.

大学運動選手恋愛経験競技生活に及ぼす影響

神戸大学学術成果リポジトリKernel http://www.lib.kobe-u.ac.jp/kernel/seika/cover/ISSN=21868719.html

棒が伸びると記録も伸びる (至言)。

2022-03-09

anond:20220308151758

無いでしょ。

JPCERT のフリをして、JP-CERT みたいな紛らわしアカウントを作って、ウイルス入りのリポジトリ作成し、

INTERNET WATCHツール公開のニュースをタレこむフリをして、偽のリポジトリを教えたら、

ケロっと騙されてしま可能性すらある。

2022-03-08

nginxとかロシア関係あるんじゃないの?

開発に影響あったりするんじゃないの?

他にもウクライナとかロシアの作者のリポジトリ普段眺めてるのがいくつかあるんだけど、今後困るのかなぁ…

🐵👨🙅

2022-03-04

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

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

361あとで/3270users 逮捕にそなえる人生継続計画 - やしお

257あとで/1505users 筑波教授が著した無料初心者向けPython教材「とてもわかりやすい」「素晴らしすぎる」 | Ledge.ai

246あとで/1545users 【独学可能英語を話す方法 第二言語習得研究行動科学に基づく英語学習ロードマップ - ポリグロトライフ | 言語まなび∞ラボ

228あとで/1502users 「1Byteが8bitに決まったワケ」についての長い話 まずは「バベッジの階差機関から | ITMedia

228あとで/1340users 1on1 ノウハウの共有 | DevelopersIO

218あとで/2069users 音声合成業界に激震! もはや人間の喋り声、入力文字読み上げソフトVOICEPEAKはビジネス用途でも自由に利用可能藤本健の “DTMステーション

172あとで/1057users 2022年ウクライナ情勢をより深く理解するための歴史文化背景雑学|tadhara|note

170あとで/912users BIOSからUEFIへ BIOSはなぜ終わらなければならなかったのか | ITMedia

168あとで/1175users 早く寝るために自分自身をハックする - 本しゃぶり

160あとで/1187users 富士通撤退する「メインフレーム」ってそもそも何? | koduki | Zenn

152あとで/854users 「界隈がざわつくほど超進化したPMBOK第7版」に私たちはどう取り組むか | 櫛田 瑞穂 | SpeakerDeck

148あとで/1128users 【登大遊天才エンジニアの安寧を求めない生き方日本で“大義”を持って働く選択は有利」 - エンジニアtype | 転職type

146あとで/1624users 元葬儀屋のワイが神奈川県警悪事淡々と話すスレ : うしみつ-5chまとめ- #神奈川

143あとで/756users 事業開発者プロダクトマネージャーが知っておくべきフレームワーク7選|Shinnote

142あとで/1250users 「Google検索は死んでいる」がバズったので「まとも検索」を作った。:村上福之の「ネットケータイ俺様」:オルタナティブブログ

138あとで/728users OSS経験「なにから始めたらいいかからない…」←これを一気に解決する神リポジトリ - Qiita

137あとで/1202users 中小企業Apple製品を利用する前にやっておくこと | Hiroshiman | Zenn

128あとで/1357users 1分でわかるウクライナ歴史 | anond.hatelabo.jp

124あとで/1265users 【MacKindle本も永久保存自動スクショPDF化する方法|脱凡リーマンブログ

124あとで/1192users これだけは押さえよう!住所フォームの作り方 - ケンオールブログ

119あとで/928users 今のウクライナ情勢が分かりやすくなる…地政学漫画紛争でしたら八田まで』が凄いと話題 | Togetter

118あとで/875users 「詩」というもの谷川俊太郎|「新潮編集部note

118あとで/955users 子ども自己肯定感を下げるNG言動 5000人を育成してわかった低い子の特徴(みらのび) - Yahoo!ニュース

115あとで/1012users 人は「楽と感じる方法しか選ばないことを前提に、仕組みを作らなければならない。 | 桃野泰徳 | Books & Apps

112あとで/1044users 定年退職後に料理をはじめた父の「大葉漬け」がヤミツキ必至の美味しさでご飯がとまらない/ 大葉の大量消費にもオススメ! | 砂子間正貫 | RocketNews24

112あとで/760users 東京都デジタル人材確保・育成基本方針 ver.1.0 | 東京都 | SpeakerDeck

111あとで/631users ソフトウェアアーキテクチャの基礎 | O'Reilly Japan

108あとで/652users ブラウザで動くサービスを作るとき技術選定 | moga | Zenn

105あとで/755users 2024年制度変更「つみたてNISA」 始めるなら2022年が有利な理由 | マネーポストWEB

104あとで/557users Webフロントエンドパフォーマンスチューニング55選 - Qiita

ウクライナを手軽に理解しようというエントリ多め

2022-02-15

githubスター数ってどれくらいある?

ソフトウェアエンジニアの皆様に質問したい。

ソフトウェアエンジニアであるのであれば、githubアカウントもあるし、自分の作ったリポジトリもあるだろう。

そのリポジトリで一番多いスター数ってどれくらいある?

どれくらいあれば面接しても大丈夫そうだなって考えることができる?

もちろん、スター数0でも素晴らしいエンジニアはいると思うけど、因果関係でなくとも相関関係確率論的な指標にはなるだろう。

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-21

普段タスク管理方法

なんかの機能追加というタスクがあるとまずタスクを分割してTODOアプリ登録する


こんな感じ。できる限り1タスク1~5分くらいで終わる量に分割する

1メソッドが大きい場合例外処理のみ、DB登録部分のみ、メール送信部分のみとかそれだけでもタスクを分ける。

30秒で終わるようなことでもタスクとして独立してたら分けて登録する

タスクを捌く際はタイマーを駆使する

「30分あれば上から12個こなせるな」とか見積もりして該当タスクに印をつけて30分タイマーで都度タイムアタックする

タイムアタックが終わると5分ほど休憩。見積もってた分が30分より早く終わってもその時点で休憩。5分くらい?

Youtube見たり在宅だったらえっちビデオ見たり音楽聞いたり好きなことをする。

終わったらまた30分分のタスクを見繕ってタイムアタック。それの繰り返し

ちなみにSlackで問い合わせとか来た場合はその時点で返信より前にTODOとして登録。何故ならそうしないと絶対返信忘れるから

2022-01-07

将来の夢はGitHuberです :-)

言語指定なしのtrendingに頻繁に出るリポジトリになりたいです

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