sedにはまる

CodeDeployを使っていてhookで動くシェルの中で設定ファイルを作っているところがあるのだが、production環境を設置してみたところ、sedで変な置き換わり方してた。
staging環境では起こらないのに・・・

例えば・・・

DATABASE_URL="mysql://userA:passwordA@localhost:3306/sample"
　↓
DATABASE_URL="mysql://userB:passwordB@[mysqlのエンドポイント]:3306/sample"

のように変えたいところがこのようなことになっていた。

DATABASE_URL="mysql://user:passDATABASE_URL="mysql://user:password@localhost:3306/sample"word@[mysqlのエンドポイント]:3306/sample"

なぜゆえに？

どうもpassとwordの間に何かがあると思い、元のパスワードを確認すると & が入ってる！！！
pass&wordのところの & がどうやら元の文字列に置き換わってしまったらしい。
これはsedコマンドの使い方の問題っぽいから調べてみたところこのような記載が。

置換後の文字列に & を指定するとマッチした文字列の部分が出力され、
, ... を指定するとマッチした文字列のうち正規表現内でカッコでグルーピングされた部分が出力される。

ちなみに & をそのまま使うようなやり方もないので、仕方なくパスワードから & を外すことにした。
& がなければ無事に置換することができました。
パスワードに記号使うのも考えものだな。

セッションマネージャーのポートフォワーディング（続編）

前の記事でポートフォーワーディングについて説明した taiyakikuroann.hatenablog.com

のですが、このやり方だと複数アカウントを扱う場合にすごくやりづらい。
悩みの種だったのですが、良さげな解消できそうな方法を見つけた！
ポートフォーワーディング自体の設定を ~/.ssh/config に書いてしまおうってことでやってみた。

~/.ssh/config にこのようにポートフォーワーディングの設定を書く

Host example_tunnel 
  HostName       i-xxxxxxxxxxxx
  User           ec2-user
  LocalForward   9999 [RDSのエンドポイント]:3306
  ProxyCommand   sh -c "aws --profile=example1 ssm start-session --target %h --document-name AWS-StartSSHSession --parameters 'portNumber=%p'"
  IdentityFile   [鍵ファイルを置いたところのパス]

HostNameにはインスタンスのIDを指定する
LocalForwardのポートとか転送先は用途に応じて変更する
ProxyCommandの--profile=example1はAWSのプロファイル名を指定

接続するときはこれでOK！

% ssh example_tunnel

サクッとできた。
この設定をアカウント毎に追加すれば複数アカウントでも管理可能！
前回の書き方だと書き直しが発生するので、この使い方のほうがおすすめ。

猫団子は嫌いなくせに…

.

ぬいぐるみには寄り添うんだわ… ツンデレ三毛猫。

wena3 初めての改造

wena3のレザーを持ってます。
が、、、夏はレザーが暑い！ので、ベルト部分を変えてみた。

[材料]

• wena
• 爪楊枝
• ベルト用に使う布製の幅15mmの帯みたいなやつ（100円ショップで見つけた）
  本当は18mmが適切だと思うけどなかった。

[作り方]
帯みたいなやつを手首のサイズよりも長めに裁断する。
裁断したままだとほつれるので、切断面をライターでちょっとだけ炙る（燃やさないでね）

爪楊枝で帯みたいなやつに２箇所穴を開ける（端と端の丁度いい場所に開ける）
レザーベルトと同じような付け方でセットする。
仕上がりこんな感じ。

15mmでも全然いけそうな感じ。（本当は18mmが正しい）
でも、レザーに比べて高級感はナッシング・・・
この辺は合わせる時計によるかな。スポーツタイプならこのままで全然OK。

とりあえず涼しくはなりました。ベトベトもしなくなりました。
寝てる間に無意識に外してしまうこともないでしょう。睡眠トラックもきっとちゃんと取れるに違いない。
自分の好きなレザーで作るもよし、布製の帯みたいなやつで作るもよし、可能性を感じます。
sonyさんも替えのベルトだけでなく、ベルトの種類を増やして欲しいものです。
というか、バックルの部分が同じならメタル⇄レザー⇄ラバーの互換くらいは付けて欲しかったな〜・・・
今後に期待。

余談ですが、歯医者にいった時に生体認証のストレス値がめっちゃ高かった。
生体認証はビミョーって意見が多いんですが、割と合ってる？とか思いました。

wena3 を買いました

スマートウォッチ何使ってますか？
やっぱりApple Watchですか？

私はwena2 activeを使ってました。
もともとAndroid使ってて（当時良さげな）ペアリングできるスマートウォッチがなかったのと、ヘッド部分が好きなものに交換可能できるのも魅力で愛用し始めてはや２年ほど経ちました。
このまま使い続けるのかと思いきや、AppleWatch使ってないんですか？という質問から調べてみたら、新しいバージョンがリリースされてることに気づいてしまって、迷いに迷った（Apple Watchとも迷ったんだが）結果購入してしまいました。

購入ポイントとしてはこんな感じ

• Suicaが使える←ポイント！wena2じゃ使えず、これがなければ、ほんと買い換えるつもりはなかった（地元の交通系ICにポイントが付かなくなったのも大きい。これはコロナのせい）
• ヘッドが変えられる
• 充電したら１週間もつ（AppleWatchは良くて２日ぐらいらしい）
• スマートウォッチが嫌な時はウェアラブルとしても使える

まぁ、Apple Watchの方が性能が良いのだが、逆に良すぎるので余計だと感じる部分もあって（使ったことないから嘘だったらごめん）心的な負担にになりそうだったので、なんとなく欲しいものどりができそうだと思ったのが一番大きいかな。
なので、他の比較とかはできないですがwena3の良かったところと悪かったところを書き記してます。 ちなみに、メタル、レザー、ラバータイプのうち、私はレザータイプを購入しました。

良かったところ

• Suicaが使えた
  ドキドキしながら改札を通ったのですが、見事にタッチ＆ゴーできた！
  iosでSuica使っていた頃は、ダブルクリックした後にマスクのせいでFace認証できなくて毎回パスコード認証してました。
  マスクしてなかったら使いやすかったんだろうけど、このちょっとしたことが耐えられなかった。最新のアップデートではAppleWatchをつけてたらパスコードを入力しなくても使えるようです。 AppleWatchかざせばそのままタッチ＆ゴーできるかも。
  めんどくささから解放されたので、とりあえずよし！

• iDが使えた iosで使う場合はおサイフリンクを使ってiDの支払いが可能！
  これはwenaに限らずのことだが、自分が使いたい機能でおサイフリンクで使えるのは便利。（おサイフリンク自体は使える機能が限定されるので微妙かも）
  私の場合は、主流がSuicaとiDだったのが使いやすいポイントだった。

• 好きなヘッドが付けられる
  アナログの好きなヘッドが付けられる。
  男性用の時計が主流。女性が使いたい場合は考えた方が良いがやり方はありそう。

• Alexa が使える Alexaが簡単な質問に答えてくれる

• 充電が長持ち
  Max充電して１週間ぐらいは持つから週末充電すればいい。とても楽である。

悪かったところ

• ヘッドをつける時のコネクターが難しい
  ヘッド（時計部分）に合わせて専用の部品が必要なのだが、知識が無い者にとってはこれがとても難しい。
  コネクト部分の幅が何ミリとかによって部品が変わってくるので、適切なものを選ぶところが至難！
  自分でカスタマイズできると思えば楽しい分野ではあるが、部品代がかさむのも微妙ポイント。

• レザータイプだと、ヘッド（時計）部分の入れ替えがやりづらい
  最初の付属部品は22mmのものです。たまたま持ってる時計も22mmで丁度良い感じだが、気分によってヘッドを交換したい時にベルト幅とヘッド幅が合ってなかったりしてカスタマイズがやりづらい感が。その日の気分による着せ替えがこのままだとできない。
  →アイデアでなんとかなりそう

• メタル⇄レザー⇄ラバーの入れ替えができない
  主要なところはバックルになるので、ベルトになる部品を互換性にして入れ替えできてもええやん・・・って思ってしまう。

• 単体で音楽が聴けない
  特に欲してない。やりたければios端末でいいや。

書いてて気づいたんだが、全部のっけが欲しいわけではなく Suica と iD と ヘッド とが欲しかった！という結論。
数日使ってみて今のところ満足している。

EC2のAutoScalingと起動テンプレートと

AWSのAutoScalingの起動設定がAMIの入れ替えがめんどくさくて使いにくいな〜って思っていたところ、 起動テンプレートという機能があって、これが使い勝手が良い！
またこの起動テンプレートと組み合わせることで、AutoScalingの設定にもバリエーションが出てくる。

ということで早速やってみよう。

起動テンプレートの作成

EC2の左のメニューから起動テンプレートを選択

右上の「起動テンプレートを作成」から始める。

後の設定はデフォルトでオッケー。
無事にテンプレートが作成できました。

次は、AutoScalingの設定。

EC2の左のメニューからAuto Scaling グループを選択

なぜかこのメニューを選ぶとメニューが英語化する。
この現象に気がついてからしばらく経つけど一向に直る気配なし。
特に困ってないし、まぁ、いいか。

起動テンプレートには先ほどのテンプレートを。

これで次へ

ここから重要。
デフォルトの設定でも良いのですが、「購入オプションとインスタンスタイプを組み合わせる」を選ぶことでAutoScalingで起動するインスタンスにスポットインスタンスを取り入れることが可能になります。
これは使い方次第でかなり節約が見込めそう

常に立ち上げておく、オンデマンドインスタンスの数と、オンデマンドとスポットの比率の調整をここで設定

ここも重要。
スポットインスタンスを多めに使う場合は、空き容量がなくなったらそもそも立ち上がらなくなるため（立ち上がってもすぐ死んだり）、使用するインスタンスタイプを分けて優先順位をつけておくことで、必要な数立ち上がらなくなるという事態を避けることができる。この時に必要なサイズに近いもので設定しておくのが良し。m5.largeとm4.largeとか。

置き場所を選んで、次へ
（Multi AZしたい場合はSubnet２つ以上選ぶこと）

ロードバランシングは一旦なしで、次へ

最大最小数を設定する。とりあえず３台動くように設定してみる。

EC2インスタンスの一覧で３台起動したことを確認できた。 オンデマンドインスタンスとスポットインスタンスの比率の調整がイマイチだったので、全部オンデマンドで立ち上がってしまいましたが、１０台立ち上げたら、２〜３台がスポットインスタンスになっていたはず。
最初に設定するオンデマンドインスタンスの１台以上にしておけば、残りは全てスポットに当てるなどの設定をしてもいいかもしれない。この辺は運用見ながら調整していけばいいところなので、稼働が始まったら動きを観察して決めていけばいいかな。

また、起動テンプレートでは、AMIに変更があった場合にテンプレート側でバージョン管理ができて、起動設定のようにAMIが変わるたびにAutoScalingへのアタッチをやり直す必要もないので、管理コストも少し減りそうな予感。

EC2のAutoScalingよりも最近はサーバレスのLambdaとかコンテナベースのECSとかが主流になってきてそうだから、使う機会も減ってくるかもしれないけど、コスト削減には起動テンプレートは知っておいた方が良いかなと思います。

セッションマネージャ+ポートフォワーディングを利用したDB接続

前回のセッションマネージャー接続の続編。
セッションマネージャーで繋いだEC2を踏み台としてDB接続やるよ。

• 前提：
  • セッションマネージャーの利用を完了させておくこと
  • EC2にキーペア鍵ファイルを設定しておくこと

さあ、やってみよう。

sshポートフォワーディングしてクライアントツールで接続するまで

ssh設定を記述

~/.ssh/configに下記を書く

host i-* mi-*
    ProxyCommand sh -c "aws ssm start-session --target %h --document-name AWS-StartSSHSession --parameters 'portNumber=%p'"

共通鍵を使うために、鍵置き場に鍵をおいておく。
鍵名：[EC2にアタッチした鍵ファイル]

sshポートフォワーディングする

ssh -i [鍵ファイル置き場所] ec2-user@[インスタンスのID] -L 5432:[rdsのエンドポイント]:3306

• コンソール上で上記コマンドを流して、トンネルを掘る。接続できたらOK。

DBに接続

接続情報： host：localhost
port：5432
username：XXXX
password：YYYY

※portは適宜変えてください。

DB接続のクライアントツールに直接SSH接続の設定ができないのが若干ビミョー（というか面倒臭い）なところではありますが、大事なデータを守るためにはこのくらいはやった方がいいのかもしれない。