「sshd」を含む日記 RSS

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

2023-12-19

ゼルダリニア回帰否定に関する海外の声3

@JaredClaunch

いくつかのダンジョンや直線的な進行に関連付けられたクエストを含むオープン マップは、間違いなく機能する可能性がありますダンジョン アイテムを進行状況に組み込むこともできますが、すべてかゼロである必要はありません。

@beans-do6wc

同意しました。 オープンワールドゲームダンジョン機能しない理由は、進歩感覚がないからです

@MachFiveFalcon

はい! 7:41 はあなたの主張をよく反映しています。 「正しい」解決策が得られたとき、私にとって特別な満足感があります。 (ただし、私は新しいオープン デザインパズルを楽しんでいます。) フックショットのような永続的なゲームプレイを変えるアイテムは、適切にデザインされたパズル使用すると、プレイヤーに真剣に考えることを強います

@lucashen9686

ほとんどの人はダンジョンが好きではありません。

なぜあなたたちはそれが理解できないのですか? 誰もがあなたのようなわけではありません。

@juicecake2458

@lucashen9686 私はそれには大いに反対しますが、私は自分自身上記の人々のことを代弁しているだけなので、確かなことはわかりません。

@amandaslough125

@lucashen9686 そして、ほとんどの人は、パズル主導のダンジョンで知られ賞賛されているゼルダ シリーズを実際には好きではありませんでした。 それはアドベンチャー ゲーム世界におけるユニークニッチでした。

@t_bone2145

まるで以前にも同じような素晴らしいゲームを作ったことがあるような気がします...咳、風が覚める、咳、咳

@FDMD_

@lucashen9686 これは荒らしコメントですよね?

@MachFiveFalcon

@lucashen9686 ブレス オブ ザ ワイルドの祠や神獣は好きでしたか? それともオープンワールドの探索、戦闘アートデザインだけだったのでしょうか?

@lucashen9686

@amandaslough125 正確に言えば、1 億人を超える Wii 所有者のうち、スカイウォード ソードを購入したのは 400 万人だけです。 ほとんどの人はゼルダが好きではありませんでした。 非常によく知られているにもかかわらず、人々がそれを避けたため、マリオの売上には及ばなかった。 BOTWが来るまでは。

でも、疎外された昔からゼルダファンにはそんなことは分からないと思うよ。

@lucashen9686

@juicecakes2458 古典的ゼルダの売上が物語っていますし、最も主流のゲーム シリーズにはダンジョンがないという事実もわかります

@lucashen9686

@MachFiveFalcon 神社も神獣も全体的には大丈夫だと思ってたけど、私としては多くの神社を諦めたけど、筋金入りの古いゼルダファン以外のほとんどの人は金を賭けてもいい、銀河系頭脳パズル面白くない 、多すぎます

BOTW で私のお気に入りの点は、探索とシーカのスレート能力です。

@juicecake2458

@lucashen9686 ビデオ ゲームが非常に広く認識されているのは助かります。 あの頃よりもずっと。 また、『トワイライト プリンセス』などのゲームは約 1,000 万本、『ゼルダ 1』は 700 万本、『時のオカリナ』は 1,400 万本を売り上げました。 それは今のToTKと同じくらいです。

@legendoffarore3711

厳密に言えば、これはボット以前のすべてのゼルダゲームと同じです。

@lucashen9686

@legendoffarore3711 そう、だからどれも 900 万本以上売れなかったのです。

@m_h_o_o_o_o

@lucashen9686 ゴミ味。 あなたは『スパイダーマン 2』が GOTY を受賞できなかったことにがっかりした人の一人のようですね。

@lucashen9686

@juicecakes2458 これは本当にでたらめです!

マリオカートって聞いたことありますか?? Wiiスポーツ?? ポケットモンスター?? GTA??

80年代以降は2,000万、3,000万ともっとたくさん売ることが可能でした。 ゼルダの売れ行きが良くなかったのは、人々がそれが何であるかを知らなかったからではなく、どこでも雑誌の表紙を飾っていなかったからではなく、ほとんどの人がゼルダを好まなかったからです。

なぜこれが受け入れがたいのか、数字を見れば明らかです。

@lucashen9686

@juicecakes2458 と時のオカリナは 700 万本売れました、何のことを言っているのかわかりません。

また、生涯売上を今年リリースされたゲーム比較しています。 非常に論理的比較です。

@thatnerdygaywerewolf9559

@lucashen9686 ということは、あなた意見に関する限り、シリーズアイデンティティの主要な側面が削除され、既存ファンが遠ざかることは、シリーズの人気をさらに高めたのだから、まったく問題ないということですか? それは、そもそも既存ファンダークソウルを好む理由であるにもかかわらず、より多くの視聴者を引き付けるためにダークソウル戦闘と挑戦を廃止すべきだと言っているようなものです。

この議論は結局、シリーズに関して重要なのは IP/ブランド名だけであり、ゲーム自体本質ではない、ということになります

@lucashen9686

@thatnerdygaywerewolf9559 もちろんです!

ビジネスお金を稼ぐために存在します。伝統的なゼルダではないという理由で最大900万人の古典的ゼルダファンがBOTWに満足していないとしても、誰が気にするでしょうか? 3000万部以上売れたんですね! 古典的ゼルダファンよりもBOTWのファンの方が多いです。 全員を喜ばせることはできません。

あなたコメントは、ほとんどのファンボーイがいかに非合理的で疎外されているかを示す完璧な例です。

@mmike

@lucashen9686 銀河系の脳パズルゼルダ赤ちゃんパズル銀河の脳だと思うなら、どうやって日常生活を乗り切るのですか?

@lucashen9686

@mmike何?? 😂😂😂 赤ちゃん向けのパズルは何ですか? 天才さん、申し訳ありませんが、私は普通人間で、ほとんどのパズル自力で解くことができますが、一部のパズルは私にはちょっと無理で、何時間も解き続ける気はありません。 ガイドを調べるだけでも楽しいものではありません。

@mmike

@lucashen9686 新しいゲームにはダンジョンもありますが、本当にひどいダンジョンです。 それが問題なのです。

@amandaslough125

@lucashen9686 まず、スカイウォード ソードWii コンソール寿命の終わりに発売されたことを忘れています。その頃、ほとんどの人は次世代を待っている間ゲーム無視し、ほとんどのゲーマーうんざりしていたモーション コントロールに焦点を当てていました。 すでに2年ほど前から流行しています移植であるにもかかわらず、SSHDスイッチですべてが売れるため、実際にスイッチでよく売れました。

第二に、所有するコンソールごとに販売されたゲームに基づくと、BotW は OoT よりも良い成績を収めませんでした。 彼らは本質的に結びついています。 そして、ほとんどのゼルダ ゲームは常にコンソールごとに所有される割合が高く、マリオ カートスマッシュのようなものにのみ抜かれています。 人々はゼルダのためにゲーム機を購入します。

最後に、一般的な主流市場では、すべての企業が同じものを作っているため、必ずしもブランドロイヤルティがあるとは限りません。 よりニッチ製品からの安定した収入は、現在市場トレンド利益を得るよりも長く持続可能です (特にオープンワールド ゲームはどれだけ売れてもお金が吸い込まれます。このため、現在 AAA 市場独自バブル崩壊させています) 傾向)。 任天堂は自らが生み出した市場シェアに参入してくる競合他社と徹底的に戦ってきたため、彼らはよりニッチ市場を切り捨て、その過程で空白を生み出しているだけだ。 そして、Buldur's Gate 3 は、「時代遅れゲームプレイ」(ターンベースRPG など)でも、実際にうまくやれば依然として十分な利益をもたらすことを証明しました。

@mmike

@lucashen9686 小さな子供たちはゼルダゲームします。 彼らを銀河頭脳と呼んだり、倒すには天才でなければならないと言うのは愚かです。 私は天才だと言いたいのではなく、彼らはそれほど難しくないだけです。 私と私の友達全員は7歳くらいのとき時のオカリナを倒し、私の甥はほぼ同じ年齢でブレス オブ ザ ワイルドのすべての祠を倒しました。

@thatnerdygaywerewolf9559

@lucashen9686 かっこいいですね。 したがって、重要なのは人気と大きな数字だけであり、実質的ものは何も気にしていないことがわかりました。

@imatiu

@juicecakes2458 この議論に対する単純な反論は、『リンクの目覚め』のリメイク版が約 700 万本売れたとか、『スカイウォード ソード』のリメイク版が 400 万本売れたというものです。

リメイクであることを考慮したとしても、『リンクスの目覚め』は 30 年前のゲームリメイクであるため、Switch コンソールを持っているほとんどの人にとってはほぼ完全な新作ゲームですが、それでも売上は『ティアーズ オブ ザ』の半分にも達していません。 王国はそうしました。

したがって、ゲーム認知度が低いということは、売上が低いという正当な議論とは思えません。

@therealpskilla502

@thatnerdygaywerewolf9559 誰もが同じ好みを持っているわけではないという事実をご指摘いただきありがとうございます。多くのゲームが優れているのは、すべての人にアピールしようとしているわけではないことです。 OoT が Wii Sports、GTA、Fortnite などに比べてほとんど売れなかったなど誰も気にしません。それでも、多くの人の意見では、OoT は史上最高のゲームの 1 つです。

@nuclearbeeberman

@therealpskilla502 しかし、任天堂は他の企業と同じようにお金を稼ぎたいと考えており、ゼルダの両方のスタイルを(少なくともAAA品質では)作る能力がありません。 外部スタジオは毎年ゼルダゲームリリースしたいと考えているので、今後さらに多くの 2D ゼルダゲームが登場すると確信していますリマスター (いずれにしても際限なくリマスターすることはできません) とウォリアーズスピンオフの間に、いくつかの新しい 2D ゲームが登場すると確信しています

@sonymicronin

@lucashen9686 それは真実ではありません 😂😂😂

@sonymicronin

@lucashen9686 あなたが彼らを嫌っているからといって、他のプレイヤーが彼らを好きではないというわけではありません 😂😂😂

2023-01-16

anond:20230116100354

いまどきはftpd立てるよりもsshd立ててscpの方がいいぞ

逆にもっと単純にやりたいならnetcat

2022-12-13

バッテリーがヘタったスマホの使い道

常に充電してないと起動すらしないスマホが手元にある

メルカリとかで売っても赤字になりそうなくらいの5年以上前のAndroid6のスマホなんだけど、何か使い道ないか悩んでるところ

できれば文鎮にするのもしのびないので活用したい

条件は以下

・boot loader unlockはできない(怪しいサイトに金払えばunlock codeをもらってできるっぽい)

上記の影響でカスタムROMは入れられない

WIFIは2.4GHz帯しか使えない

・性能はローからドル程度

・32GBの容量があったが、OSなどでいろいろ容量を取られて半分以上は埋まっている

この上で以下をためしていた

 

・termuxを入れて実質Linux機とする

termuxというアプリを入れるとshellが使えるようになり、sshdも起動するとPCからSSH接続して操作可能になる

色々試したけど、専用のパッケージマネージャが最新バージョンパッケージは扱えるが、過去バージョンアーカイブしてないのか取れないことが判明し

やりたいことが実質できない状態になったので終了。自力過去バージョンビルドしてみたけどarm64なのがいけないのかうまく動かなかった。

あと性能低すぎてEC2とかの最小インスタンスでもそこまで時間からず終わる処理が30分以上待たされたりしたので実用するにはハードルが高かった

 

Alexaアプリを入れて声で操作する

Alexaアプリハンズフリー発話の設定を入れればAlexaのほぼすべての機能が使えるのでいい体験になった

しかし、他のAlexaからスマホAlexaは見えないので他のAlexaから呼びかけ等ができず終了

スピーカースマホのじゃたかがしれてるもんね

 

・Android6の検証機とする

今日日6なんて古いバージョンサポートしなくてもよくなったので終了

 

以下はまだちゃんと試してない事

監視カメラ

スマホ自体監視カメラにして何かしらのアプリで見られるようにする

懸念点はそこまでカメラの性能が高くない事と、外に設置する場合に電源をどう確保するか、防水をどうするかが悩みどころな点

 

スマートホーム操作用のリモコンハブにする

なんかそういうアプリがあることは知っている

使用頻度の高いところに掛けておけば使いやすいかもしれない

懸念点は持ち運びできないことと、電源の確保

 

他になにかよさそうな使い方あれば教えて欲しい

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

2018-09-20

PS4HDDを2TBに換装したら快適すぎワロタ

元々500GBだったものを2TBに換装した

PS+とかセールゲームを購入してたんだけど

HDDの空きが足りなくて積んでるゲームをわざわざ消したり再インストールしたりが面倒だった

2TBに換装してそれが一気になくなって快適すぎ

SSDにすることも考えたけど

そこまで時間が足りないわけでもないし

めちゃめちゃゲームしてるわけでもないので採用しなかった

代わりにSSHDを導入した

これで充分だった

2016-06-27

Windows Subsystem for Linux ひさしぶりに触ったらだいぶまともになってた

リリース直後だと apt-get update && apt-get upgrade でそのまま壊滅的に環境が壊れるという状態で話にならなかったのだが、

現状残っている問題点としては

あたり。

Mac 上で Linux サーバーで動くアプリを作ることが出来るぐらいには Linux サーバーで動くアプリを作れるようになっている気がする。

2016-04-05

http://anond.hatelabo.jp/20160405160227

公開鍵パスワードは盗まれても問題無いですよね。

秘密鍵が盗まれるケースというのはどういう状況を想定していますか? ウィルス感染

2段階認証は確かに強力ですが、別デバイス登録とか、サーバ側の仕組みとか、コストかかりますよね。

公開鍵認証だったら sshd 立ち上げるだけ。

2016-02-17

SSHD for Windows を使ってみた

SSHD for Windows とは

Windows サーバsshサーバを立てる時に使います

結果

Macからrsyncしようとすると、謎のエラーが発生。

SSH接続はできるんだけどな。

これ、使いもんにならんわ。

2015-11-24

MacBook Pro 2011 でのBOOTCAMP環境下でのハイブリッドHDD(SSHD)の使用について

MBP2011ハイブリッドHDD(SSHD)に換装し、BOOTCAMPに新しくWindowsインストールしたら、猛烈に動作が遅い。ずーっとプチフリーズ状態で困り果ててた。Windows7でもダメWindows8でもダメWindows10でもダメ

タスクマネージャを見ると、ディスクちょっとした軽微なアクセスでもすぐに100%になってしまうことが原因というところまではわかり、1週間いろいろ試行錯誤して解決した。

原因は

TRIMコマンド

だと予測されます。少なくとも私の環境では、以下の方法でばっちり治りました。

1、コマンドプロンプト管理者権限にて起動

2、以下のコマンド入力

fsutil behavior query DisableDeleteNotify

3、コマンド入力の結果、「DisableDeleteNotify=0」であればTRIM有効であることを確認

 ふつうSSDであれば、これで良いのですが、私の環境ではこれが原因で非常にWindowsが遅かった。

 というわけで、これを無効化します。

4、TRIM無効化

fsutil behavior set DisableDeleteNotify 1

入力します。入力したとたん快適になりました。

SSDの人はこれやると寿命が縮んだりするらしいので、気を付けてくださいね

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