.ebextensions の container_commands の挙動メモ - Qiita
EB_IS_COMMAND_LEADER が設定されてるのを確認できました。 container_command の属性値を leader_only: true とした場合、複数インスタンスにデプロイする場合であっても Beanstalk によって選択された単一のインスタンス (＝リーダー) でしかコマンドが実行されませんが、その際のリーダーかどうかの判定に使用されている変数のようです。 自身がリーダーかどうかは /opt/elasticbeanstalk/bin/leader-test.sh のスクリプトでも判定可能です。 pwd の結果: /var/app/current になってました。デプロイするとこのディレクトリ以下にアプリケーションが展開されます。 残された疑問点 次の記事を読むと以下のように書かれています。 container_command実行時には /var/app/on
UUIDを重複させるにはどれだけ時間がかかるのか試してみた
絶対に重複しないといわれるUUID UUIDとはUniversally Unique Identifier の略で、「Universally」つまり将来にわたって重複や偶然の一致が起こらないという前提で使われるIDのことです。 128ビットで表現されるUUIDは2^128通り（Version 4では固定値があるため2^122通り）あり、その膨大なパターンから将来に渡って重複しないとされています。その特性から、ファイルのハッシュ値に使われたり、DBのキーに使われたりしています。重複しないことが約束されているので、大変使い勝手が良いのです。 とはいえ、有限桁数である以上は重複が発生する可能性がごく僅かながら存在します。 では実際に重複させるには、どれだけUUIDを作らないといけないのか試してみます。 まずは計算で目算をつける x通りのパターンがあるとき、衝突回数がpになるときの試行回数nは以下
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
