fluid_27’s blog

勉強した内容をアウトプットするためのブログ

そういえばttyって何?

記事で紹介されている通り、何気なく以下のようなコマンドを打った。
docker-compose exec -T xxx

えーと、-Tオプションって何?

-Tオプションとは

Disable pseudo-TTY allocation. By default docker compose exec allocates a TTY.

https://docs-stage.docker.com/reference/cli/docker/compose/exec/



なるほど。擬似 TTY 割り当てを無効にすると。


で、TTYって何?

TTY(teletypewriter)とは、利用者が入力した文字を別の機器に送信したり、別の機器から受信した文字情報を利用者に提示したりする機能を持った端末やソフトウェアのこと。

https://e-words.jp/w/TTY.html#:~:text=TTY%EF%BC%88teletypewriter%EF%BC%89%E3%81%A8%E3%81%AF%E3%80%81,%E7%AB%AF%E6%9C%AB%E3%82%84%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E3%81%AE%E3%81%93%E3%81%A8%E3%80%82

ttyとは、標準入出力となっている端末デバイス(制御端末、controlling terminal)の名前を表示するUnix系のコマンドである。元来ttyとはteletypewriter(テレタイプライター)のことを指す。

https://ja.wikipedia.org/wiki/Tty

ま、分かるような分からんような。

chatGPTにも聞いてみた

-Tオプションは、Dockerコマンドの標準出力にtty(端末)を割り当てないことを指定します。通常、Dockerコンテナに対するexecコマンドを実行すると、標準入出力にttyが割り当てられ、コンテナ内のプロセスが端末として扱われます。しかし、-Tオプションを使用すると、この割り当てを行わず、標準入出力を単なるストリームとして扱います。

例えば、docker-compose exec -T xxxを実行すると、コンテナxxxに対してttyを割り当てずにコマンドが実行されます。このオプションは、スクリプトバッチ処理などでDockerコマンドを実行する際に、不要なttyの割り当てを防ぐために使用されることがあります。

つまり、-Tオプションを付与しないと入出力用のtty(端末)が1つのプロセスとして割り当てられる。ということらしい。

ちなみに、ttyの割り当てをしないことのメリットは?

リソースの節約: ttyの割り当ては、追加のリソース(メモリやCPU)を消費します。特に大規模なスクリプトバッチ処理を実行する場合、これらのリソースの消費を最小限に抑えることが重要です。

バッチ処理の自動化: サーバー環境でDockerコンテナを使用してバッチ処理を実行する場合、通常は人間の介入なしで自動化されます。そのような場合、ttyの割り当ては必要ありません。-Tオプションを使用することで、バッチ処理をスムーズに自動化できます。

出力の整形: ttyを割り当てると、出力が端末に合わせて整形されることがありますが、これはスクリプトや自動化された処理にとっては不要な場合があります。-Tオプションを使用することで、出力がスクリプトに適した形式で得られます。

総じて、不要なttyの割り当てを防ぐことで、リソースの節約や自動化プロセスの効率化が図れます。

お世話になったブログ記事 6月

改めてレプリケーションを復習。
qiita.com

zenn.dev

AWSの構成で参考に。
https://pages.awscloud.com/rs/112-TZM-766/images/AWS%E8%A8%AD%E8%A8%88%E3%81%AE%E3%83%98%E3%82%99%E3%82%B9%E3%83%88%E3%83%95%E3%82%9A%E3%83%A9%E3%82%AF%E3%83%86%E3%82%A3%E3%82%B9%E3%81%A6%E3%82%99%E6%9C%80%E4%BD%8E%E9%99%90%E7%9F%A5%E3%81%A3%E3%81%A6%E3%81%8A%E3%81%8F%E3%81%B8%E3%82%99%E3%81%8D10%E3%81%AE%E3%81%93%E3%81%A8_20200617_rev.pdf

個人的にはSSRとSSGの区別はついていると思っていた。SPA、MPAも絡めた際の関係性というか区別をしっかりしてくれているのが助かった。
zenn.dev

このあたりのアーキテクチャは勉強していきたい。
qiita.com

このあたりはより深堀りが必要だと感じている。
qiita.com

業務でLPページのパフォーマンスチューニングを行ったので上記のような記事は大変参考になった。
qiita.com

社内での共同開発でdocker環境いじったので、docker関連のブログいくつか参考にした。
shiimanblog.com

qiita.com

zenn.dev

qiita.com

sizu.me

自己学習でCI/CDの構築を行っているのでgithub actionsやECS周りについて
zenn.dev

zenn.dev

iret.media

dev.classmethod.jp

qiita.com

phpとnginxの通信の種類、unixソケット or tcpの違い、またそららのdockerfileへの記載について
techblog.roxx.co.jp

zenn.dev

https://web-designer.cman.jp/javascript_ref/window/size/

基本技術者試験対策の用語一覧

使用性

ISO/IEC 9126(JIS X 0129)として定義されているソフトウェア品質特性の1つで「分かりやすさ、使いやすさの度合い」をいう。

セル生産方式

製造業における生産方式の一種で、1人若しくは少数の作業者チームで製品の組み立て工程を完成(または検査)まで行うもの。
作業者の周囲に機械、組付工具及び部品が配置され、その中を歩き回って作業をする。
ライン生産方式などの従来の生産方式と比較して、作業者一人が受け持つ範囲が広く多品種を生産するときフレキシブルな切り替え可能なのが特徴。

プリエンプション

複数のタスクを同時に実行するマルチタスク(マルチプログラミング)に対応したOSの制御機能のひとつで、実行状態のタスクを一旦停止して、実行可能状態に戻すこと
「実行可能状態」のタスクにCPUの使用権を割り当て「実行状態」にすることをディスパッチといい、逆に「実行状態」のタスクを一旦停止して「実行可能状態」に戻すことをプリエンプションという。

プリエンプティブ

プリエンプションを利用する(実行の途中でCPUの使用権を奪うことができる)タスクスケジューリング方式。

ノンプリエンプティブ

プリエンプションを利用しない(実行の途中でCPUの使用権を奪うことができない)タスクスケジューリング方式。

バッファキャッシュ

キャッシュメモリ・データベースバッファキャッシュ)はアクセスされたデータファイル内にあるデータをいったんメモリ上に展開し、保持しておくメモリ領域のこと。

ヒット率

キャッシュメモリにCPUが必要とするデータが存在する確率のこと。

EVM

(Earned Value Management)は、プロジェクトにおける作業を金銭の価値に置き換えて定量的に実績管理をする進捗管理手法。
EVMではPV,EV,ACの3つの指標を用いて管理するのが特徴。
各指標を比較して、EV-ACがマイナス値であれば完了済み作業に対する予算よりも投入コストが多いのでコスト超過、EV-PVがマイナス値であれば完了済み作業に対する予算が当初の予算よりも少ないので進捗遅れ、と判断することができる。

PV

(Planned Value)プロジェクト開始当初、現時点までに計画されていた作業に対する予算

EV

(Earned Value)現時点までに完了した作業に割り当てられていた予算

AC

(Actual Cost)現時点までに完了した作業に対して実際に投入した総コスト

パケットフィルタリング

パケットのヘッダ情報内のIPアドレス及びポート番号を基準にパケット通過の可否を決定する

IDS

(Intrusion Detection System,侵入検知システム)は、ネットワークやホストをリアルタイムで監視し、異常を検知した場合に管理者に通知するなどの処置を行うシステム。異常を通知することを目的としたシステムのため通信の遮断などの防御機能を持たないことがほとんど。
またIDSはその用途から、ネットワークの通信を監視するネットワーク型IDS(NIDS)と、サーバなどにインストールされ、そのマシンの挙動を監視するホスト型IDS(HIDS)に分類される。

DRAM

(Dynamic Random Access Memory)は、コンデンサ電荷を蓄えることにより情報を記憶し、電源供給が無くなると記憶情報も失われる揮発性メモリ。集積度を上げることが比較的簡単にできるためコンピュータの主記憶装置として使用されている。
コンデンサに蓄えられた電荷は時間が経つと失われてしまうので、DRAMでは記憶内容を保持するための「リフレッシュ操作」を随時行う必要がある。

SRAM

フリップフロップ回路と呼ばれる2つの安定な状態を持つ素子で構成されている。フリップフロップは、2つの反対の信号を受け取り、その結果に応じて情報を0または1のビットで表現する。
このフリップフロップ回路は常に電力を必要とし、電源がオフになるとデータが消失する。一方で、コンデンサを使用しないため、DRAMよりも高速なアクセスが可能。SRAMキャッシュメモリレジスタファイルなどの高速なメモリとして使用される。

問題管理プロセス

インシデントや障害発生の根本原因を突き止め、インシデントの再発防止のための恒久的な解決策を提示することを目的とするプロセス。
主な活動は以下の通り。
・インシデントの根本原因と潜在的な予防処置を特定する
・問題解決のための変更要求を提起する
・サービスへの影響を低減又は除去するための処置を特定する
・既知の誤りを記録する

インシデント管理プロセス

利用者に対する正常なITサービスの妨げになる事象に対応して、サービス利用を続行できるようにする。

ITサービス継続性管理プロセス

ITサービス継続性管理プロセスの目標は、インシデントが必然的に発生したときに効率的で標準化されたプロセスを配置することにより、インシデントのダウンタイム、コスト、業務への影響を軽減すること。

フェールセーフ

システムの不具合や故障が発生したときでも、障害の影響範囲を最小限にとどめ、常に安全を最優先にして制御を行う考え方。
例えば、「工業用機械で進入禁止区域をセンサーで監視し、人や物の侵入を感知したときには機械を緊急停止する」、「信号機が故障した時は全てを赤信号にする」というような設計がフェールセーフの実践例。

フェールソフト

システムの一部に障害が発生した場合に、全体の機能が完全に停止することなく、縮退しつつも動作しつづける設計思想。

フォールトトレランス

機器やシステムなどが持つ性質の一つで、構成要素の一部が故障、停止などしても予備の系統に切り替えるなどして機能を保ち、稼動を続行できること。
また、そのような仕組みや設計方針。

フールプルーフ

不特定多数の人が操作しても,誤動作が起こりにくいように設計。
「人がミスをしようとしてもできないようにする工夫」のこと。

ゼロデイ攻撃

(zero-day attack)とは、あるOSやソフトウェアに脆弱性が存在することが判明し、ソフトウェアの修正プログラムがベンダーから提供されるより前に、その脆弱性を悪用して行われる攻撃のこと。

アクチュエータ

(Actuator)は、入力された電気信号を力学的な運動に変換する駆動機構で、機械や電気回路の構成要素。制御システムにおいては、コントローラーから制御信号を受けとり制御対象に与える操作量を変化させる部位のこと。

2相コミット

(Two Phase Commit)は、トランザクションのコミットを次の2つの段階に分けて行うことで、分散データベース環境でのトランザクションの原子性・一貫性を保証する仕組み。
第1フェーズ→ 他のサイトに更新可能かどうかを確認する
第2フェーズ→ 全サイトからの合意が得られた場合に更新を確定する

ファンクションポイント法

外部入出力、ファイル、外部インターフェイスなどの数と複雑さ・難度などの因子をもとにファンクションポイント数を算出し、それを基にして開発工数を見積る方法

プログラムステップ法

開発するプログラムごとのステップ数を積算し,開発規模を見積る方法。

ペネトレーションテスト

ネットワークに接続されている情報システムに対して、様々な方法を用いて実際に侵入を試みることで脆弱性の有無を検査するテスト。
代表的なものとしてOSやサーバソフトウェアに対して実施されるものと、Webアプリケーションに対して実施されるものがあり、実施に関してもセキュリティスキャナーなどの市販製品やフリーソフトなどを活用することで多岐にわたる項目について効率的な実施が可能。

ウォークスルー

開発者が主体となりエラーの早期発見を目的としてプログラムのステップごとにシミュレーションを行いながら確認をしていくレビュー手法。

ソフトウェアインスペクション

ソフトウェアを実際に動かすことなく、仕様書やプログラムを人間の目で見て検証するレビュー手法。

リグレッションテスト

退行テスト/回帰テストとも呼ばれ、システムに変更作業を実施した場合に、それによって以前まで正常に機能していた部分に不具合や影響が出ていないかを検証するテスト。

実際に行っているGitの運用

実際に現場で採用していたgit運用のメモ。
プロジェクトの大きさなどにより最適解は変わってくると思うので、あくまで1つの形として。

ブランチ戦略

Github Flowを踏襲。

Github Flowだと
・main
・feature/*
ブランチで運用するのが基本的な運用方法かと思うが、

上記にdevelopブランチを加えて
・main
・develop
・feature/*
ブランチの3つで運用している。

developブランチの扱いとしては統合ブランチのようなもの。
feature/*で各機能ごとに開発した機能をdevelopブランチにマージすることで、CI/CDが走り開発環境に自動デプロイされる運用となっている。
メンバーはdevelopにマージさせることで実際の挙動を確かめられる。

各ブランチの説明

mainブランチ

本番環境のブランチで、リリースするために使う。
ここでは直接コミットせず、マージのみ行う。
※ mainブランチ上では開発を行わない。

developブランチ

mainブランチから派生させて作成。
developへPRを出し、CIでの自動テストが通った時点で自動で開発環境へデプロイされる。

featureブランチ

mainから派生させ、各々担当の開発箇所を開発。
完了したら、develop・main両方へそれぞれマージさせる。
新機能の追加や、不具合の修正やリファクタリングなどは全てfeatureブランチで行う。
機能追加・不具合修正・リファクタリングなどの実装種類によって細かくブランチを分けることはしない。

ラベル

・新規作成
・修正
・優先度(高・中・低)
のラベルを用意。

新規作成 or 修正は名前の通り、どういうPRなのかが一目でわかるように適切なラベルを設定する。

優先度(高・中・低)のラベルの関しては、レビュアーがレビューだけでなく他タスクも抱えていて、レビュー進捗が悪化した時期があった為、優先度をつけるようにした。
具体的には
・優先度高・・・共通処理など、影響の大きい実装。他処理に関わるバグ修正など
・ 〃  中・・・決められたスケジュール内で進行している実装
・ 〃  低・・・スケジュールに対して先行着手している実装

assignee

担当者が分かるように。担当者自身を設定する。

reviewer

レビュアーとして2人を指名しないとマージできない設定。

所感

他のブランチ戦略としてはGit Flowなどがあると思うが、開発段階では特に管理するブランチが多すぎてデメリットの方が強い気がするので、
個人的にはプロジェクトの規模やフェーズにもよるが、大体はGithub Flowを踏襲する形が最適解になるかと思っている。
ただ、Github Flowは細かくPRを出しながら進めていく。という形になると思うので、その分レビュアーに負担がかかっていた。

途中からレビューがどんどん貯まる一方になっていて、レビュアーの負担を減らす策として、優先度をラベル付けして、緊急性の高いもの・すぐに取り組まなくてもいいものを明示するようにした。

この辺はより最適解があると思う。(他にも出た案としては、マイルストーンなどを使って締切日を設定できるようにしたら?とか)
今回のをサンプルケースの1つとして、今後もそのプロジェクトの規模・フェーズにあったGit運用方法を探っていきたい。