ENTRYPOINTは「必ず実行」、CMDは「（デフォルトの）引数」 ‣ Pocketstudio.Net
CMD と ENTRYPOINT の違い 先日の勉強会で Dockerfile における「CMD」と「ENTRYPOINT」の使い分けについて質問がありました。結論からしますとタイトル通り、ENTRYPOINTは「必ず実行」、CMDは「（デフォルトの）引数」なのですが、初学者にとっては分かりづらいところ。デモを交えながら、ブログでも改めて説明します。 （違いについては、既にいろいろなトコロでも言及されていますが、初学者向けにまとめました。私自身、初めて両者に触れた時は、全く理解できなかった！という思いもあります） コンテナ実行時の挙動と「CMD」命令 まず前提として、次のコマンドを実行したら、なぜ bash が起動するか分かりますか。コンテナ実行後にプロセスを確認しますと、/bin/bash がコンテナ内で PID 1 として動いています。 $ docker container run -
フィットネス用スピンバイクをVRCで使うことについて。｜しえら
フィットネスバイクを漕ぐことでVRの自分も動くシステムを開発したみっちーさん @Dream_Drive と部長？のしえらさん @super_sierra 、マツリーさん @Matsu__Ree 、こたのわさん @kotanowaと走ってきたよ🎵最高だ💗https://t.co/EjSbzRYh3U ↑ ショート動画もいいねしてね💕#VRCフィットネスバイク pic.twitter.com/i8F3yUnVQF — ききょうぱんだ @Vketアンバサダー / VR歌劇団座長 (@kikiki_kikyo) April 23, 2023 ここまでの経緯みっちーさんのジョバンニつい10日程前(23/3/16)のこと。疑似フルトラデバイス『だみとら』の件で、ツイッターで親交のある、みっちーさんとお会いすることができました。（訪ねてきていただきました、誠にありがたき…！） 僕はついつい、自分の
役割をお願いする時に伝えていること - Konifar's ZATSU
マネジメントを4年くらいやっている間に、何人かにEngineering managerや採用のリードなどの役割をお願いして担ってもらってきた。何か新しい役割をお願いする時に整理して伝えている項目を雑にまとめておきたい。 以下のようなGoogle docsを作って共有し、30分のミーティングで直接伝えて考えてもらうようにしている。タイトルは「◯◯さんにxxをお願いしたい」みたいな感じ。項目や内容は相手によって適宜変えてる。 これは何 「◯◯さんにxxをお願いして一緒にやっていきたいと考えています」みたいな感じでストレートにお願いしたい役割を書く 「命令ではなく、なぜお願いしたいか、何をお願いしたいかなど◯◯さんに意思決定する材料を渡すためのdocsです」のようにまだあくまで提案ですよということも書く なぜ今お願いしたいか プロダクトや組織の状況も踏まえて、"今"お願いしたい理由を書く その役
既存のDeploy Preview環境をmirage-ecsに移行する - 設計編 - Hatena Developer Blog
マンガメディア第2チームでGigaViewerのWeb面のSREを担当している id:s-shiro です。 この記事は、はてなのSREが毎月交代で書いているSRE連載の10月号です。9月の記事はid:cohalzさんの新規事業「toitta」で導入したGoogle Cloudのセキュリティ機能の紹介でした。 リポジトリのブランチごとに、メインブランチにマージする前の動作確認に使える環境を起動することをPreview DeployやDeploy Previewと呼ぶらしいのですが(以下Deploy Preview)、マンガメディアチームではEC2で構築していたDeploy Preview環境を、メンテナンス性や使い勝手の観点からコンテナ化しようとしています。 はてな全体でみるとDeploy Preview環境の構成や要素技術は、歴史的な経緯もあり各サービスを開発するチームごとに異なっており
小規模プロダクトにおける React 状態管理ライブラリ選定 in 2024 - バイセル Tech Blog
はじめに こんにちは！ テクノロジー戦略本部24年新卒の高橋です。 2023年の10月から内定者インターンを経験し、現在は開発3部CRMチームでフロントエンド(以後、FE)エンジニアとして働いております。 チーム内でFEの状態管理ライブラリを選定する機会があり、調査していく中で得た知見を共有したく、執筆に至りました。 少しでも状態管理ライブラリの選定に困っているFEエンジニアの参考になればと考えています。 はじめに 概要 前提 課題感 Context APIの思想とのズレ Context APIの記述量の多さ 状態管理ライブラリに求める要素 小さい単位で取り扱い可能 ボイラーテンプレートが少なく、APIが直感的で書き方の自由度が高くない 軽量 Reactアプリケーション内外での状態管理が可能 最終決定 検討候補 Redux Zustand Jotai Valtio 評価表 移行設計 既存C
Terraform だけだとハードモードなので Terragrunt を使おう - Qiita
Terraform はそのままだと管理が大変 みなさん IaC (Infrastructure as Code) してますか？パブリッククラウドをIaCするなら、 Terraform が便利ですね！ しかし、本格的に使い始めると、こういう問題がすぐに出てきます。 複数環境の楽な分け方を知りたい ワークスペースはなんか嫌だ とはいえ、環境間で共通するボイラープレートをどうにかしたい 環境内で適用するモジュールを細分化・分岐したいけど面倒 環境ごとに使うモジュールを切り替えたい テスト環境はAuroraではなく安いRDSにしたい モジュール(tfstate)を分割して小さい範囲で適用したい 大きなモジュールは影響範囲がわからないし、差分計算にそれなりに時間がかかってしまう 分けたモジュールを一括適用するのが面倒 モジュール間の依存関係がわからない モジュール(tfstate)間での値参照が面倒
Herokuでredisのバージョンアップグレード
本記事では、Herokuで提供されているHeroku Data for RedisというRedisアドオンのバージョンアップの方法を記載します。 RailsアプリでのRedis6.2から7.2へのバージョンアップを例として使用しますが、他のフレームワークやバージョンでもやり方はほぼ一緒なはずです。また、6.2から7.0, 7.0から7.2のように間に7.0へのアップグレードを挟まなくても、直接6.2から7.2へのアップグレードが可能です。 なお、Redisがオープンソースではなくなったことが原因で、Herokuではバージョン7.2からはRedisではなくRedisをフォークしたオープンソースのValkeyを使って同様の機能を提供しています。本番環境でのアップグレード手順は変わりませんが、ローカル環境ではそれに伴ってvalkeyを使ってテストするようにします。 ローカル環境での事前確認 He
AWSのコストを45%削減した話 その1 - coincheck tech blog
こんにちは、最近 30 MINUTES SISTERS にはまっている、SRE Gの渡邉です。今回で2回目になります。 昨今、AWSのコスト削減が流行っていたりするみたいですが、弊社も時流に遅れることなく？AWSのコスト削減を行ったので、その話を何回かにわけて書いていきたいと思います。 まずは成果から 絶対値はあれなので、数字はないですが、どん AWSのコストエクスプローラー、償却コスト、サービス別より 5月から12月で、およそ 45% の削減となっております。ってタイトルに既に書いていましたね。 なお、Reserved InstancesやSavings Plansで2、3月に期限が切れるものがあるので、更に削減がされることが想定されています。 はじまり 春の終わり頃に、本部長からコスト削減の話がでてきました。 まぁ暗号資産の相場はわかっているし、公表されている決算の数字だってもちろん理
やんないほうがいいかも、GitHub Actions の setup-xxx での依存キャッシュ保存 - 誰かの役に立てばいいブログ
GitHub Actions で CI している皆様、こんにちは。 GitHub Actions 便利ですよね。使わない日がないというくらい毎日お世話になっています。 さて、CI といえば良く問題になるのが実行時間。 長い待ち時間は開発効率を下げますし、プライベートリポジトリだと Runner の費用も嵩んでしまいます。 時間を短縮する方法は色々ありますが、一手目によく行われるのが依存パッケージのキャッシュじゃないかなと思います。 例えば Go で開発していると、依存パッケージは ~/go/pkg/mod にダウンロードして保存されます。 これを CI 実行のたびにダウンロードしてコンパイルするのは時間とお金の無駄というものです。 幸い、GitHub Actions には CI の実行間でこういった依存パッケージを保存して再利用できるキャッシュ機能があります。 詳しくは以下のドキュメントを
ECS FargateでSeleniumを実行する
はじめに こんにちは、GMOソリューションパートナーのTKです。 当社には、AWSの学習用のアカウントがあります。 今回はそれを活用して、ローカルのdocker環境上で動かしていたSeleniumを ECSのFargateで動作させてみることにしました。 構成 root ├ python │ └ Dockerfile │ └ requirements.txt │ └ script.py ├ selenium │ └ Dockerfile └ docker-compose.yml コード pythonディレクトリ配下 FROM python:3.12 ENV TZ Asia/Tokyo RUN apt-get update && \ apt-get install -y sudo vim && \ apt-get clean COPY ./ /app RUN pip install -r /
生成AI入門 - AWS社員が解説するAmazon Bedrock詳細ハンズオン - Findy Tools
公開日 2024/09/05更新日 2024/09/06生成AI入門 - AWS社員が解説するAmazon Bedrock詳細ハンズオン はじめにAmazon Bedrockは、業界をリードする種々の基盤モデル（Foundation Model・FM）を提供する、生成AIアプリケーションの構築に必要な幅広い機能を備えたフルマネージドサービスです。 生成AIを業務で導入するには、モデル選びやセキュリティなど、さまざまなことを考える必要があります。 Amazon Bedrockは、APIを通じて生成AIの基盤モデルを利用できるだけでなく、付随するサービスによってお客様が生成AIを簡単に導入できます。 Amazon BedrockはAWSマネジメントコンソール上でモデルを有効化し、API経由で入力を送信するだけで使用できます。コンソールでモデルを試したり、複数モデルを比較したりすることもできます
reboot/shutdown後も設定を維持したい場合はulimit -nではなく/etc/security/limits.confを編集する(「Too many open files」「ファイルを開きすぎています」エラー対策) - Qiita
reboot/shutdown後も設定を維持したい場合はulimit -nではなく/etc/security/limits.confを編集する(「Too many open files」「ファイルを開きすぎています」エラー対策)CentOSRHELRHEL7centos7 RHEL7/CentOS7上で開発や運用をしていると「Too many open files」「ファイルを開きすぎています」といったエラーが出ることがあります。これはファイルディスクリプタの枯渇が原因であり、その上限値を調整することが対策法となります。 さて調査の結果、ファイルディスクリプタの上限値はulimit -nにより設定できることが分かったのですが――ulimitによる設定は一時的な効力しかなく、rebootやshutdownをすると、もともとの値に戻ってしまいます。 [root@localhost ~]# ul
Linux サーバでの「Too many open files」対策について - akishin999の日記
Linux サーバでの「Too many open files」エラー対策について調べたのでまとめてみました。 確認した OS は CentOS 5.9 と CentOS 6.3 です。 「Too many open files」は Linux でプロセスが開けるファイルディスクリプタの上限に達してしまうと発生するエラーです。 「ファイルディスクリプタ」という名前ですが、 Linux ではソケットもファイルディスクリプタなので、ファイルを開いた場合だけでなく、ソケットを使って通信を行う場合にもファイルディスクリプタが使用されます。 そのため、Apache や Tomcat などで高負荷なサイトを運用している場合などには、比較的遭遇する確率の高いエラーではないでしょうか。 このエラーを回避するため、プロセスがオープンできるファイルディスクリプタの上限を変更します。 まずは以下のコマンドを実行
Amazon Verified Permissionsな世界とAmazon API Gateway - Qiita
はじめに AWS Verified AccessやAmazon Verified Permissionsって紛らわしいですよね。どっちがどっちだかわからなくなるところなのですが、今回は、Amazon Verified Permissionsを使った認可制御についてのアーキテクチャを考えます。 ゴールとしては、Amazon Verified Permissionsはどんなやつなのか理解する、です。 Amazon Verified Permissionsとは Amazon Verified Permissionsは、アプリケーションのアクセス許可の管理およびきめ細かな承認サービスです。制御については、ポリシー言語である Cedar を使用して、ロールと属性を使用してポリシーベースのアクセス制御を定義し、よりきめ細かくコンテキストに応じたアクセス制御を行うことができます。 単純に認可だけするサー
Amazon S3が「条件付き書き込み」に対応。既にオブジェクトがある場合は上書きせず、分散アプリケーションでの利用が容易に
Amazon Web Servicesは、オブジェクトストレージを提供する「Amazon S3」の新機能として「条件付き書きこみ」（Conditional Writes）をサポートしたことを発表しました。 条件付き書き込みを利用すると、オブジェクトの書き込み時にオブジェクトの存在をチェックし、オブジェクトが存在しない時だけ書き込む、という指定が可能になります。 これにより、アプリケーションがデータをAmazon S3に書き込む際に、既存のオブジェクトを上書きすることを簡単に防ぐことができるようになります。 例えば、複数のクライアントが同一オブジェクトにデータを書き込んでいくような分散処理において、不用意に既存のデータを上書きしないように書き込む直前にオブジェクトを確認するといった処理をアプリケーションで作りこむ必要がなくなり、Amazon S3に任せることができるため、Amazon S3を
DMARCポリシー「none」または DMARC 対応していないドメイン名のなりすましフィッシングメール増加傾向、7 月のフィッシング報告状況 | ScanNetSecurity
フィッシング対策協議会は8月21日、2024年7月のフィッシング報告状況を発表した。
お名前.comからRoute53にドメイン移管する - Qiita
概要 お名前.comのドメインをRoute53に移管する際、設定で迷ったのでメモしておく。 ドメインの移管 移管可能なドメイン 移管する際は、下記条件を満たしている必要があるようです。 ドメインレジストラに登録後、60日経過している 期限切れのドメインの場合、期限切れから60日経過している ドメインレジストラに移管してから、60日経過している ドメインのステータスコードが次の状態でないこと ※ pendingDelete, pendingTransfer, redemptionPeriod, clientTransferProhibited ドメインのステータスコードは、whoisコマンドで確認 ドメイン設定の確認 (お名前.com） ドメインの設定内容をチェックする。 > お名前.com Navi -> ドメイン ※ ドメインを移行できるようにアンロックになっているか？ ※ ドメインの登
Terraform担当大臣 - laiso
“Platform Engineering”という私的よく見かけるが意味を調べたことのない用語No.1のトピックについて書かれた本がO'Reillyからearly releaseされているので読んでる。まだ第一部しか公開されてない。 learning.oreilly.com その中に出てくるアプリケーションチームがTerraformコードを管理することで起きがちな問題について共感したので紹介する アプリケーションエンジニアリングチームがIaaSクラウドのあらゆるものを求めるようになったとき、多くの企業は、各チームに独自のクラウドインフラストラクチャを独自の構成でプロビジョニングする権限と責任を与えることが、摩擦の少ない方法だと判断しました。 実際には、これは、構成管理とインフラストラクチャプロビジョニングに精通した、兼業のクラウドエンジニアリングチームになることを意味していました。 繰り返
systemdにバグ．/home以下のファイルが全削除される可能性あり - pyopyopyo - Linuxとかプログラミングの覚え書き -
systemdのバージョン256に /homeディレクトリ以下のファイルを削除してしまうバグがあったそうで，修正版の 256.1 がリリースされています． systemdのissuesによると，一時ファイルを一括削除する systemd-tmpfiles --purge コマンドが /home以下を不要ファイルと誤判定して削除するそうです tmpファイルを消すだけのコマンドと見せかけて，home以下も消すという邪悪なバグなので注意が必要です． 心配な人は systemd のバージョンを確認しておきましょう systemdのバージョンの確認方法 以下のコマンドを実行してsystemdのバージョンを確認します $ systemctl --version バグ有り，/homeが消える可能性がある場合 １行目にsystemd 256 (256-1)と表示されます．バグあり版です．何かの拍子に/ho
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AWS FargateでAutoScaleを試してみる - Qiita
