<h1 id="rails7.1%E3%82%A2%E3%83%97%E3%83%AA%E3%82%92%E7%88%86%E9%80%9F%E3%81%A7ecs%E3%81%AB%E3%83%87%E3%83%97%E3%83%AD%E3%82%A4%E3%81%99%E3%82%8B%E3%81%9E%EF%BC%81"><a class="header-anchor-link" href="#rails7.1%E3%82%A2%E3%83%97%E3%83%AA%E3%82%92%E7%88%86%E9%80%9F%E3%81%A7ecs%E3%81%AB%E3%83%87%E3%83%97%E3%83%AD%E3%82%A4%E3%81%99%E3%82%8B%E3%81%9E%EF%BC%81" aria-hidden="true"></a> Rails7.1アプリを爆速でECSにデプロイするぞ！</h1>
こんにちは。プロダクト開発部の小木です。
今期のイチオシ特撮はウルトラマンブレーザーです。（個人的に冷めがちだった）近年のヒーロー特撮によくあるコレクションアイテム商法を廃した骨太な作品で毎週楽しみに観ています。
ところで、去る2023年10月5日にRails7.1がリリースされましたね。7.1からは <code>rails new</code> をするとDockerfileがデフォルトで生成されるようになりました。
そこで今回はこれを使ってRailsアプリをAWS Fargateにデプロイしていこうと思います。
検証目的なのでデータベースはデフォルトSQLiteで。コンテナもrailsコンテナひとつのみ起動する単純な構成でいきます。
<h2 id="rails%E3%82%A2%E3%83%97%E3%83%AA%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6"><a class="header-anchor-link" href="#rails%E3%82%A2%E3%83%97%E3%83%AA%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6" aria-hidden="true"></a> Railsアプリについて</h2>
Railsアプリは <a href="https://github.com/rails/docked" target="_blank" rel="nofollow noopener noreferrer">docked</a> を使ってセットアップしました。
dockedを使うと手元の開発環境にRubyやRailsをインストールせずにRailsアプリを立ち上げることができます。
<div class="code-block-container"><pre class="language-bash"><code class="language-bash">docked rails new myapp
docked rails server
</code></pre></div>アプリケーションが起動できたのを確認後、以下の変更をしました。
<div class="code-block-container"><pre class="language-bash"><code class="language-bash">docked rails g scaffold post title:string contents:text author:string
docked rails db:migrate
</code></pre></div><div class="code-block-container"><pre class="language-ruby"><code class="language-ruby">Rails.application.routes.draw do
 resources :posts
 # Define your application routes per the DSL in https://guides.rubyonrails.org/routing.html

 # Reveal health status on /up that returns 200 if the app boots with no exceptions, otherwise 500.
 # Can be used by load balancers and uptime monitors to verify that the app is live.
 get "up" =&gt; "rails/health#show", as: :rails_health_check

 # Defines the root path route ("/")
 root "posts#index" # 追記
end
</code></pre></div>ALBからのヘルスチェックをhttpで受けるため <code>force_ssl</code> をfalseにしています（理由は後述）。検証目的なので雑にfalseに変更していますが、業務等で実装する場合は ALBからのリクエストのみfalseにする、等の工夫が必要そうです。
<div class="code-block-container"><pre class="language-ruby"><code class="language-ruby">config.force_ssl = false # falseに変更
</code></pre></div>ヘルスチェック用のURL（<a href="http://0.0.0.0:3000/up" target="_blank" rel="nofollow noopener noreferrer">http://0.0.0.0:3000/up</a> ）にアクセスして一面緑のページが確認できました。Railsアプリ側の準備はこれでOKです。
<h2 id="copilot-cli%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6"><a class="header-anchor-link" href="#copilot-cli%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6" aria-hidden="true"></a> Copilot CLIについて</h2>
copilotというと GitHub Copilotが有名ですが、AWS Copilot CLIというツールがAWSから公開されています。AWS Copilot CLIは、アプリケーションのデプロイを簡素化するためのツールです。このCLIを使用すると、Railsアプリを簡単にAmazon ECSにデプロイできます。
AWS Copilot CLIを使用すると、以下のようなAWSのリソースを作成できます。
<ul>
<li>Amazon ECSクラスター</li>
<li>タスク定義</li>
<li>コンテナイメージのビルドとデプロイ</li>
<li>ロードバランサー</li>
<li>ロググループ</li>
<li>アプリケーションのスケーリング設定</li>
</ul>
（インストール方法や初期設定は省略します。<a href="https://aws.github.io/copilot-cli/ja/docs/getting-started/install/" target="_blank" rel="nofollow noopener noreferrer">公式ドキュメント</a>で丁寧に説明されているのでそちらを見てください。ローカライズもされています。）
<h2 id="copilot-cli%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%9F%E3%83%87%E3%83%97%E3%83%AD%E3%82%A4"><a class="header-anchor-link" href="#copilot-cli%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%9F%E3%83%87%E3%83%97%E3%83%AD%E3%82%A4" aria-hidden="true"></a> copilot cliを使ったデプロイ</h2>
以下のコマンドを実行後にいくつかの質問に回答します。
<div class="code-block-container"><pre class="language-ruby"><code class="language-ruby">copilot init

Use existing application: No
Application name: myapp

 Which workload type best represents your architecture? [Use arrows to move, type to filter, ? for more help]
 Request-Driven Web Service (App Runner)
 &gt; Load Balanced Web Service (Public. ALB by default. Internet to ECS on Fargate)
 Backend Service (Private. ALB optional. ECS on Fargate)
 Worker Service (Events to SQS to ECS on Fargate)
 Static Site (Internet to CDN to S3 bucket)
 Scheduled Job (Scheduled event to State Machine to Fargate)

Service name: myapp

 Which Dockerfile would you like to use for myapp? [Use arrows to move, type to filter, ? for more help]
 &gt; ./Dockerfile
 Enter custom path for your Dockerfile
 Use an existing image instead

</code></pre></div>このまま回答内容に問題なければそのままAWS側にアプリケーションがデプロイされます。
が、最初はヘルスチェックに失敗してコンテナが起動・停止を繰り返してデプロイに失敗してしばらくハマりました。
原因は前述した <code>force_ssl</code> 設定で、ALBからのヘルスチェックはhttpで送信されるため、Railsアプリ側がhttpsではないそのリクエストを弾いてしまっていたことが原因でした。
大量にログが表示されますが、デプロイに成功すると以下のような出力がされます。ここに記載されているURLにアクセスすると
<div class="code-block-container"><pre class="language-ruby"><code class="language-ruby">✔ Deployed service myapp-service.
Recommended follow-up action:
 - You can access your service at http://myapp--Publi-bAUWZB7S2oKu-1675675588.ap-northeast-1.elb.amazonaws.com over the internet.
</code></pre></div>ログの最後に表示されるURLにアクセスすると以下のようにアプリが表示されました。 
いいですね！
<img src="/images/posts/deploy-rails7_1-with-aws-copilot-cli/Myapp.png" alt="Myapp.png" />
最終的に以下のような copilot/myapp-service/manifest.ymlになりました。
<code>healthcheck</code> と <code>RAILS_MASTER_KEY</code> あたりを追記しています。RAILS_MASTER_KEYについても本来は以下のようにベタ書きすべきではないですが、検証目的ということで。manifest.yml内でのシークレットの取り扱いについても公式ドキュメントでは解説されていますので、それに従うと良いでしょう。
<div class="code-block-container"><pre class="language-ruby"><code class="language-ruby">name: myapp-service
type: Load Balanced Web Service

http:
 path: '/'
 healthcheck:
 path: '/up'
 port: 3000

image:
 build: Dockerfile
 port: 3000

cpu: 256
memory: 512
count: 1
exec: true
network:
 connect: true

variables:
 RAILS_MASTER_KEY: # config/master.keyに記載されているマスターキーを記述

</code></pre></div>routes.rbにヘルスチェック用のパスが用意されているため、healthcheckの項でそのパスを指定しています。ここに対してALBからヘルスチェックのリクエストが飛んできます。
<div class="code-block-container"><pre class="language-ruby"><code class="language-ruby"> get "up" =&gt; "rails/health#show", as: :rails_health_check
</code></pre></div><div class="code-block-container"><pre class="language-ruby"><code class="language-ruby">I, [2023-11-04T13:50:35.619248 #1] INFO -- : [1c63372e-4e4d-48c4-a386-afacaf5b4672] Started GET "/up" for 127.0.0.1 at 2023-11-04 13:50:35 +0000
I, [2023-11-04T13:50:35.620205 #1] INFO -- : [1c63372e-4e4d-48c4-a386-afacaf5b4672] Processing by Rails::HealthController#show as HTML
I, [2023-11-04T13:50:35.620705 #1] INFO -- : [1c63372e-4e4d-48c4-a386-afacaf5b4672] Completed 200 OK in 0ms (Views: 0.2ms | ActiveRecord: 0.0ms | Allocations: 114)
</code></pre></div><h2 id="%E3%81%BE%E3%81%A8%E3%82%81"><a class="header-anchor-link" href="#%E3%81%BE%E3%81%A8%E3%82%81" aria-hidden="true"></a> まとめ</h2>
ということでRails7.1アプリを copilotを使うことで簡単にFargateにデプロイすることができました。
今回DBはSQLiteになっていますが本運用時にはMySQLやPostgreSQLを利用することになると思います。そういう場合はRDSを同じVPC内に別途用意しておいて接続情報を環境変数で渡すとかやり方を考える必要がありますね。
「VPCやセキュリティグループの設定をイチからやるのは今の時代ちょっとな、、だけどRailsアプリをクラウドに乗せたいな」という場合に有力な選択肢になるのではないでしょうか。 
また、Railsでデータベースを使わないというのはあまりないかもしれませんが、データを加工して右から左に受け流すようなマイクロサービスとか、APIモードでVPCの閉域網の中に生息するマイクロサービスなどアイデア次第で便利に使えるのではないかと思います。
是非是非こちらのcopilotのほうもよろしくお願いします。


Rails7.1アプリを爆速でECSにデプロイするぞ！

こんにちは。プロダクト開発部の小木です。

今期のイチオシ特撮はウルトラマンブレーザーです。（個人的に冷めがちだった）近年のヒーロー特撮によくあるコレクションアイテム商法を廃した骨太な作品で毎週楽しみに観ています。

ところで、去る2023年10月5日にRails7.1がリリースされましたね。7.1からは rails new をするとDockerfileがデフォルトで生成されるようになりました。

そこで今回はこれを使ってRailsアプリをAWS Fargateにデプロイしていこうと思います。

検証目的なのでデータベースはデフォルトSQLiteで。コンテナもrailsコンテナひとつのみ起動する単純な構成でいきます。

Railsアプリについて

Railsアプリは docked を使ってセットアップしました。

dockedを使うと手元の開発環境にRubyやRailsをインストールせずにRailsアプリを立ち上げることができます。

docked rails new myapp
docked rails server

アプリケーションが起動できたのを確認後、以下の変更をしました。

docked rails g scaffold post title:string contents:text author:string
docked rails db:migrate

Rails.application.routes.draw do
  resources :posts
Define your application routes per the DSL in https://guides.rubyonrails.org/routing.html

Reveal health status on /up that returns 200 if the app boots with no exceptions, otherwise 500.
Can be used by load balancers and uptime monitors to verify that the app is live.
  get "up" => "rails/health#show", as: :railshealthcheck

Defines the root path route ("/")
  root "posts#index" # 追記
end

ALBからのヘルスチェックをhttpで受けるため force_ssl をfalseにしています（理由は後述）。検証目的なので雑にfalseに変更していますが、業務等で実装する場合は ALBからのリクエストのみfalseにする、等の工夫が必要そうです。

config.force_ssl = false # falseに変更

ヘルスチェック用のURL（http://0.0.0.0:3000/up ）にアクセスして一面緑のページが確認できました。Railsアプリ側の準備はこれでOKです。

Copilot CLIについて

copilotというと GitHub Copilotが有名ですが、AWS Copilot CLIというツールがAWSから公開されています。AWS Copilot CLIは、アプリケーションのデプロイを簡素化するためのツールです。このCLIを使用すると、Railsアプリを簡単にAmazon ECSにデプロイできます。

AWS Copilot CLIを使用すると、以下のようなAWSのリソースを作成できます。

Amazon ECSクラスター
タスク定義
コンテナイメージのビルドとデプロイ
ロードバランサー
ロググループ
アプリケーションのスケーリング設定

（インストール方法や初期設定は省略します。公式ドキュメントで丁寧に説明されているのでそちらを見てください。ローカライズもされています。）

copilot cliを使ったデプロイ

以下のコマンドを実行後にいくつかの質問に回答します。

copilot init

Use existing application: No
Application name: myapp

  Which workload type best represents your architecture?  [Use arrows to move, type to filter, ? for more help]
    Request-Driven Web Service  (App Runner)
  > Load Balanced Web Service   (Public. ALB by default. Internet to ECS on Fargate)
    Backend Service             (Private. ALB optional. ECS on Fargate)
    Worker Service              (Events to SQS to ECS on Fargate)
    Static Site                 (Internet to CDN to S3 bucket)
    Scheduled Job               (Scheduled event to State Machine to Fargate)

Service name: myapp

  Which Dockerfile would you like to use for myapp?  [Use arrows to move, type to filter, ? for more help]
  > ./Dockerfile
    Enter custom path for your Dockerfile
    Use an existing image instead

このまま回答内容に問題なければそのままAWS側にアプリケーションがデプロイされます。

が、最初はヘルスチェックに失敗してコンテナが起動・停止を繰り返してデプロイに失敗してしばらくハマりました。

原因は前述した force_ssl 設定で、ALBからのヘルスチェックはhttpで送信されるため、Railsアプリ側がhttpsではないそのリクエストを弾いてしまっていたことが原因でした。

大量にログが表示されますが、デプロイに成功すると以下のような出力がされます。ここに記載されているURLにアクセスすると

✔ Deployed service myapp-service.
Recommended follow-up action:
  You can access your service at http://myapp--Publi-bAUWZB7S2oKu-1675675588.ap-northeast-1.elb.amazonaws.com over the internet.

ログの最後に表示されるURLにアクセスすると以下のようにアプリが表示されました。
いいですね！

Myapp.png

最終的に以下のような  copilot/myapp-service/manifest.ymlになりました。

healthcheck  と RAILSMASTERKEY あたりを追記しています。RAILSMASTERKEYについても本来は以下のようにベタ書きすべきではないですが、検証目的ということで。manifest.yml内でのシークレットの取り扱いについても公式ドキュメントでは解説されていますので、それに従うと良いでしょう。

name: myapp-service
type: Load Balanced Web Service

http:
  path: '/'
  healthcheck:
    path: '/up'
    port: 3000

image:
  build: Dockerfile
  port: 3000

cpu: 256
memory: 512
count: 1
exec: true
network:
  connect: true

variables:
  RAILSMASTERKEY: # config/master.keyに記載されているマスターキーを記述

routes.rbにヘルスチェック用のパスが用意されているため、healthcheckの項でそのパスを指定しています。ここに対してALBからヘルスチェックのリクエストが飛んできます。

  get "up" => "rails/health#show", as: :railshealthcheck

I, [2023-11-04T13:50:35.619248 #1]  INFO -- : [1c63372e-4e4d-48c4-a386-afacaf5b4672] Started GET "/up" for 127.0.0.1 at 2023-11-04 13:50:35 +0000
I, [2023-11-04T13:50:35.620205 #1]  INFO -- : [1c63372e-4e4d-48c4-a386-afacaf5b4672] Processing by Rails::HealthController#show as HTML
I, [2023-11-04T13:50:35.620705 #1]  INFO -- : [1c63372e-4e4d-48c4-a386-afacaf5b4672] Completed 200 OK in 0ms (Views: 0.2ms | ActiveRecord: 0.0ms | Allocations: 114)

まとめ

ということでRails7.1アプリを copilotを使うことで簡単にFargateにデプロイすることができました。

今回DBはSQLiteになっていますが本運用時にはMySQLやPostgreSQLを利用することになると思います。そういう場合はRDSを同じVPC内に別途用意しておいて接続情報を環境変数で渡すとかやり方を考える必要がありますね。

「VPCやセキュリティグループの設定をイチからやるのは今の時代ちょっとな、、だけどRailsアプリをクラウドに乗せたいな」という場合に有力な選択肢になるのではないでしょうか。
また、Railsでデータベースを使わないというのはあまりないかもしれませんが、データを加工して右から左に受け流すようなマイクロサービスとか、APIモードでVPCの閉域網の中に生息するマイクロサービスなどアイデア次第で便利に使えるのではないかと思います。

是非是非こちらのcopilotのほうもよろしくお願いします。


Rails7.1アプリをAWS Copilot CLIでAWS Fargateにデプロイする


こんにちは。お盆休みは子ども経由で手足口病にかかり、両手足の指全体に水疱ができて2日ほど寝たきり生活を送っていた小木です。おかげでウォッチリストの消化が捗りました。
この歳まで風邪すらまともにかかったことのないのが自慢だったのですが、寄る年波には勝てないのか、それとも保育園経由でかかる病気が強力なのか。。

・・・・

と、夏の終わりに書いた記事を放置していて今になってやっと整備しました。

はじめに

さて、前回はAmplifyのマニュアルビルドの方法について調べました。
これはAmplifyを既存のCodePipelineに組み込むためでしたが、ではCodePipelineにどうやって組み込めばいいのか。
CodePipelineに新たなデプロイアクションを追加し、そこで実行するCodeBuildにてReactアプリケーションをビルドしてあげればなんとかなりそうです。最終的にビルドした生成物をS3にアップロードできさえすればあとは前回の仕組みによってデプロイが完了しますね。

CodeBuildとは？

AWSの提供するフルマネージドなビルドサービスです。動作環境にDockerイメージを用いることでどんなアプリケーションでもビルドすることが可能です。

https://aws.amazon.com/jp/codebuild/

ローカルでCodeBuildを試す

実運用中の環境でいきなり CodeBuildのリソースを作成するのは気がひけます。
なので、ローカル環境でCodeBuildが動くようにして、その中でビルド内容を定義した buildspec.yml  の中身を作り込んでいこうと思います。
以下のドキュメントを参考にCodeBuildローカルの実行環境を整えます。

AWS CodeBuild エージェントを使用してビルドをローカルで実行

https://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/use-codebuild-agent.html

Reactアプリをビルドしたいので、ドキュメントに記載されているイメージではなくNode.jsのイメージで行いました。

https://gallery.ecr.aws/docker/library/node

ビルドに使用するイメージを変えた以外は基本的にドキュメントに記載されている通りの操作です。

ビルドに使用するコンテナイメージをpull
docker pull public.ecr.aws/docker/library/node:16.16.0-alpine3.16

CodeBuildエージェントをpull
docker pull public.ecr.aws/codebuild/local-builds:latest

実行用スクリプトのダウンロード
wget https://raw.githubusercontent.com/aws/aws-codebuild-docker-images/master/localbuilds/codebuildbuild.sh
chmod +x codebuild_build.sh

さて、では buildspec.yml を用意します。

buildspec.ymlとはCodeBuildで行うビルド内容を定義したファイルですね。最終的に以下のようになりましたが、

Version: 0.2
phases:
 install:
   runtime-versions:
     nodejs: 16
   commands:
     apk update && apk upgrade
 pre_build:
   commands:
     npm install
 build:
   commands:
     npm run build
artifacts:
  base-directory: build
  paths:
    '*/'
cache:
  paths:
    './node_modules/*/'

初めて実行するときは以下のように文字列を表示するだけにしてみると良さそうです。

Version: 0.2
phases:
 build:
   commands:
     echo "Hello CodeBuild"

実行コマンドは以下のようになります。

$ ./codebuild_build.sh -i public.ecr.aws/docker/library/node:16.16.0-alpine3.16 -a artifacts

実行結果はこのように。

(ビルド時に出力されるWarningは放置していますとりあえず、、）

$ ./codebuild_build.sh -i public.ecr.aws/docker/library/node:16.16.0-alpine3.16 -a artifacts
Build Command:

docker run -it -v /var/run/docker.sock:/var/run/docker.sock -e "IMAGE_NAME=public.ecr.aws/docker/library/node:16.16.0-alpine3.16" -e "ARTIFACTS=/Users/ogiyuto/Work/reactjs/cloudscape-sandbox/artifacts" -e "SOURCE=/Users/ogiyuto/Work/reactjs/cloudscape-sandbox" -e "INITIATOR=ogiyuto" public.ecr.aws/codebuild/local-builds:latest

Removing agent-resourcesbuild1 ... done
Removing agent-resourcesagent1 ... done
Removing network agent-resources_default
Removing volume agent-resourcessourcevolume
Removing volume agent-resourcesuservolume
Creating network "agent-resources_default" with the default driver
Creating volume "agent-resourcessourcevolume" with local driver
Creating volume "agent-resourcesuservolume" with local driver
Creating agent-resourcesagent1 ... done
Creating agent-resourcesbuild1 ... done
Attaching to agent-resourcesagent1, agent-resourcesbuild1
agent_1  | [Container] 2022/08/17 05:19:18 Waiting for agent ping
agent1  | [Container] 2022/08/17 05:19:20 Waiting for DOWNLOADSOURCE
agent1  | [Container] 2022/08/17 05:22:01 Phase is DOWNLOADSOURCE
agent1  | [Container] 2022/08/17 05:22:01 CODEBUILDSRC_DIR=/codebuild/output/src828330173/src
agent_1  | [Container] 2022/08/17 05:22:01 YAML location is /codebuild/output/srcDownload/src/buildspec.yml
agent_1  | [Container] 2022/08/17 05:22:01 Processing environment variables
agent_1  | [Container] 2022/08/17 05:22:01 [WARN] Skipping install of runtimes. Runtime version selection is not supported by this build image.
agent_1  | [Container] 2022/08/17 05:22:01 Moving to directory /codebuild/output/src828330173/src
agent1  | [Container] 2022/08/17 05:22:01 Expanded cache path ./nodemodules/*/
agent_1  | [Container] 2022/08/17 05:22:01 Registering with agent
agent_1  | [Container] 2022/08/17 05:22:01 Phases found in YAML: 3
agent_1  | [Container] 2022/08/17 05:22:01  INSTALL: 2 commands
agent1  | [Container] 2022/08/17 05:22:01  PREBUILD: 1 commands
agent_1  | [Container] 2022/08/17 05:22:01  BUILD: 1 commands
agent1  | [Container] 2022/08/17 05:22:01 Phase complete: DOWNLOADSOURCE State: SUCCEEDED
agent_1  | [Container] 2022/08/17 05:22:01 Phase context status code:  Message:
agent_1  | [Container] 2022/08/17 05:22:01 Entering phase INSTALL
agent_1  | [Container] 2022/08/17 05:22:01 Running command apk update && apk upgrade
agent1  | fetch https://dl-cdn.alpinelinux.org/alpine/v3.16/main/x8664/APKINDEX.tar.gz
agent1  | fetch https://dl-cdn.alpinelinux.org/alpine/v3.16/community/x8664/APKINDEX.tar.gz
agent_1  | v3.16.2-31-gfe918834c6 [https://dl-cdn.alpinelinux.org/alpine/v3.16/main]
agent_1  | v3.16.2-35-g8b5106c6a8 [https://dl-cdn.alpinelinux.org/alpine/v3.16/community]
agent_1  | OK: 17024 distinct packages available
agent_1  | OK: 8 MiB in 16 packages
agent_1  |
agent_1  | [Container] 2022/08/17 05:22:03 Running command apk add aws-cli zip
agent_1  | (1/27) Installing libbz2 (1.0.8-r1)
agent_1  | (2/27) Installing expat (2.4.8-r0)
agent_1  | (3/27) Installing libffi (3.4.2-r1)
agent_1  | (4/27) Installing gdbm (1.23-r0)
agent_1  | (5/27) Installing xz-libs (5.2.5-r1)
agent_1  | (6/27) Installing mpdecimal (2.5.1-r1)
agent1  | (7/27) Installing ncurses-terminfo-base (6.3p20220521-r0)
agent1  | (8/27) Installing ncurses-libs (6.3p20220521-r0)
agent_1  | (9/27) Installing readline (8.1.2-r0)
agent_1  | (10/27) Installing sqlite-libs (3.38.5-r0)
agent_1  | (11/27) Installing python3 (3.10.5-r0)
agent_1  | (12/27) Installing groff (1.22.4-r1)
agent_1  | (13/27) Installing py3-six (1.16.0-r1)
agent_1  | (14/27) Installing py3-dateutil (2.8.2-r1)
agent_1  | (15/27) Installing py3-docutils (0.16-r4)
agent_1  | (16/27) Installing py3-jmespath (0.10.0-r2)
agent_1  | (17/27) Installing py3-urllib3 (1.26.9-r0)
agent_1  | (18/27) Installing py3-botocore (1.21.49-r1)
agent_1  | (19/27) Installing py3-s3transfer (0.5.1-r0)
agent_1  | (20/27) Installing py3-colorama (0.4.4-r2)
agent_1  | (21/27) Installing yaml (0.2.5-r0)
agent_1  | (22/27) Installing py3-yaml (6.0-r0)
agent_1  | (23/27) Installing py3-asn1 (0.4.8-r2)
agent_1  | (24/27) Installing py3-rsa (4.8-r0)
agent_1  | (25/27) Installing aws-cli (1.22.81-r0)
agent_1  | (26/27) Installing unzip (6.0-r9)
agent_1  | (27/27) Installing zip (3.0-r9)
agent_1  | Executing busybox-1.35.0-r17.trigger
agent_1  | OK: 141 MiB in 43 packages
agent_1  |
agent_1  | [Container] 2022/08/17 05:22:18 Phase complete: INSTALL State: SUCCEEDED
agent_1  | [Container] 2022/08/17 05:22:18 Phase context status code:  Message:
agent1  | [Container] 2022/08/17 05:22:18 Entering phase PREBUILD
agent_1  | [Container] 2022/08/17 05:22:18 Running command npm install
agent_1  | npm WARN ERESOLVE overriding peer dependency
agent_1  | npm WARN While resolving: react-resizable@1.11.1
agent_1  | npm WARN Found: react@18.2.0
agent1  | npm WARN nodemodules/react
agent_1  | npm WARN   react@"^18.2.0" from the root project
agent_1  | npm WARN   12 more (@cloudscape-design/collection-hooks, ...)
agent_1  | npm WARN
agent_1  | npm WARN Could not resolve dependency:
agent_1  | npm WARN peer react@"0.14.x || 15.x || 16.x || 17.x" from react-resizable@1.11.1
agent1  | npm WARN nodemodules/@cloudscape-design/components/node_modules/react-resizable
agent_1  | npm WARN   react-resizable@"^1.11.1" from @cloudscape-design/components@3.0.10
agent1  | npm WARN   nodemodules/@cloudscape-design/components
agent_1  | npm WARN
agent_1  | npm WARN Conflicting peer dependency: react@17.0.2
agent1  | npm WARN nodemodules/react
agent_1  | npm WARN   peer react@"0.14.x || 15.x || 16.x || 17.x" from react-resizable@1.11.1
agent1  | npm WARN   nodemodules/@cloudscape-design/components/node_modules/react-resizable
agent_1  | npm WARN     react-resizable@"^1.11.1" from @cloudscape-design/components@3.0.10
agent1  | npm WARN     nodemodules/@cloudscape-design/components
agent_1  | npm WARN ERESOLVE overriding peer dependency
agent_1  | npm WARN While resolving: react-resizable@1.11.1
agent_1  | npm WARN Found: react-dom@18.2.0
agent1  | npm WARN nodemodules/react-dom
agent_1  | npm WARN   react-dom@"^18.2.0" from the root project
agent_1  | npm WARN   4 more (@cloudscape-design/components, ...)
agent_1  | npm WARN
agent_1  | npm WARN Could not resolve dependency:
agent_1  | npm WARN peer react-dom@"0.14.x || 15.x || 16.x || 17.x" from react-resizable@1.11.1
agent1  | npm WARN nodemodules/@cloudscape-design/components/node_modules/react-resizable
agent_1  | npm WARN   react-resizable@"^1.11.1" from @cloudscape-design/components@3.0.10
agent1  | npm WARN   nodemodules/@cloudscape-design/components
agent_1  | npm WARN
agent_1  | npm WARN Conflicting peer dependency: react-dom@17.0.2
agent1  | npm WARN nodemodules/react-dom
agent_1  | npm WARN   peer react-dom@"0.14.x || 15.x || 16.x || 17.x" from react-resizable@1.11.1
agent1  | npm WARN   nodemodules/@cloudscape-design/components/node_modules/react-resizable
agent_1  | npm WARN     react-resizable@"^1.11.1" from @cloudscape-design/components@3.0.10
agent1  | npm WARN     nodemodules/@cloudscape-design/components
agent_1  | npm WARN ERESOLVE overriding peer dependency
agent_1  | npm WARN While resolving: react-virtual@2.10.4
agent_1  | npm WARN Found: react@18.2.0
agent1  | npm WARN nodemodules/react
agent_1  | npm WARN   react@"^18.2.0" from the root project
agent_1  | npm WARN   12 more (@cloudscape-design/collection-hooks, ...)
agent_1  | npm WARN
agent_1  | npm WARN Could not resolve dependency:
agent_1  | npm WARN peer react@"^16.6.3 || ^17.0.0" from react-virtual@2.10.4
agent1  | npm WARN nodemodules/@cloudscape-design/components/node_modules/react-virtual
agent_1  | npm WARN   react-virtual@"^2.8.2" from @cloudscape-design/components@3.0.10
agent1  | npm WARN   nodemodules/@cloudscape-design/components
agent_1  | npm WARN
agent_1  | npm WARN Conflicting peer dependency: react@17.0.2
agent1  | npm WARN nodemodules/react
agent_1  | npm WARN   peer react@"^16.6.3 || ^17.0.0" from react-virtual@2.10.4
agent1  | npm WARN   nodemodules/@cloudscape-design/components/node_modules/react-virtual
agent_1  | npm WARN     react-virtual@"^2.8.2" from @cloudscape-design/components@3.0.10
agent1  | npm WARN     nodemodules/@cloudscape-design/components
agent_1  |
agent_1  | up to date, audited 1482 packages in 9s
agent_1  |
agent_1  | 205 packages are looking for funding
agent_1  |   run npm fund for details
agent_1  |
agent_1  | 6 high severity vulnerabilities
agent_1  |
agent_1  | To address all issues (including breaking changes), run:
agent_1  |   npm audit fix --force
agent_1  |
agent_1  | Run npm audit for details.
agent_1  |
agent1  | [Container] 2022/08/17 05:22:28 Phase complete: PREBUILD State: SUCCEEDED
agent_1  | [Container] 2022/08/17 05:22:28 Phase context status code:  Message:
agent_1  | [Container] 2022/08/17 05:22:28 Entering phase BUILD
agent_1  | [Container] 2022/08/17 05:22:28 Running command npm run build
agent_1  |
agent_1  | > cloudscape-sandbox@0.1.0 build
agent_1  | > react-scripts build
agent_1  |
agent_1  | Creating an optimized production build...
agent_1  | Compiled with warnings.
agent_1  |
agent_1  | [eslint]
agent_1  | src/App.js
agent_1  |   Line 9:8:  'Editor' is defined but never used  no-unused-vars
agent_1  |
agent_1  | src/components/Cards.js
agent_1  |   Line 10:1:  Assign arrow function to a variable before exporting as module default  import/no-anonymous-default-export
agent_1  |
agent_1  | src/components/Editor.js
agent_1  |   Line 4:1:   Assign arrow function to a variable before exporting as module default  import/no-anonymous-default-export
agent_1  |   Line 8:19:  'setLoading' is assigned a value but never used                         no-unused-vars
agent_1  |
agent_1  | src/components/Table.js
agent_1  |   Line 10:1:  Assign arrow function to a variable before exporting as module default  import/no-anonymous-default-export
agent_1  |
agent_1  | Search for the keywords to learn more about each warning.
agent_1  | To ignore, add // eslint-disable-next-line to the line before.
agent_1  |
agent_1  | File sizes after gzip:
agent_1  |
agent_1  |   82.62 kB  build/static/js/main.1a6fd71a.js
agent_1  |   31.86 kB  build/static/css/main.d2a0b07d.css
agent_1  |
agent_1  | The project was built assuming it is hosted at /.
agent_1  | You can control this with the homepage field in your package.json.
agent_1  |
agent_1  | The build folder is ready to be deployed.
agent_1  | You may serve it with a static server:
agent_1  |
agent_1  |   npm install -g serve
agent_1  |   serve -s build
agent_1  |
agent_1  | Find out more about deployment here:
agent_1  |
agent_1  |   https://cra.link/deployment
agent_1  |
agent_1  |
agent_1  | [Container] 2022/08/17 05:22:57 Phase complete: BUILD State: SUCCEEDED
agent_1  | [Container] 2022/08/17 05:22:57 Phase context status code:  Message:
agent1  | [Container] 2022/08/17 05:22:57 Entering phase POSTBUILD
agent1  | [Container] 2022/08/17 05:22:57 Phase complete: POSTBUILD State: SUCCEEDED
agent_1  | [Container] 2022/08/17 05:22:57 Phase context status code:  Message:
agent_1  | [Container] 2022/08/17 05:22:57 Expanding base directory path: build
agent_1  | [Container] 2022/08/17 05:22:57 Assembling file list
agent_1  | [Container] 2022/08/17 05:22:57 Expanding build
agent_1  | [Container] 2022/08/17 05:22:57 Expanding file paths for base directory build
agent_1  | [Container] 2022/08/17 05:22:57 Assembling file list
agent_1  | [Container] 2022/08/17 05:22:57 Expanding */
agent_1  | [Container] 2022/08/17 05:22:57 Found 12 file(s)
agent_1  | [Container] 2022/08/17 05:22:57 Preparing to copy secondary artifacts
agent_1  | [Container] 2022/08/17 05:22:57 No secondary artifacts defined in buildspec
agent1  | [Container] 2022/08/17 05:22:57 Phase complete: UPLOADARTIFACTS State: SUCCEEDED
agent_1  | [Container] 2022/08/17 05:22:57 Phase context status code:  Message:
agent-resourcesbuild1 exited with code 0
Aborting on container exit...

じっさいのCodeBuildでは ビルドによる生成物（artifact）はS3へアップロードされますが、

ローカルの場合は codebuild_build.sh の引数で指定した場所に生成されます。

$ tree artifacts
artifacts
└── artifacts.zip

0 directories, 1 file

artifacts.zipを解凍してみると、このように。

$ tree artifacts/artifacts

artifacts/artifacts
├── asset-manifest.json
├── favicon.ico
├── index.html
├── logo192.png
├── logo512.png
├── manifest.json
├── robots.txt
└── static
    ├── css
    │   ├── main.d2a0b07d.css
    │   └── main.d2a0b07d.css.map
    └── js
        ├── main.1a6fd71a.js
        ├── main.1a6fd71a.js.LICENSE.txt
        └── main.1a6fd71a.js.map

3 directories, 12 files

npm run build で生成されたファイルが含まれていることが確認できました。

困ったこと

ここまで順調に進んでいるように見えますが、私の環境では codebuild_build.sh の処理が完了するまで、M1Macで40分、IntelMacで3分ほどかかっています。
（ARM用のCodeBuildイメージが提供されているのですが、それを使っても同じ実行時間でした）

ということで 今回の検証は プライベート開発用の IntelMacで行いました。幸い今回の検証ではReactのビルドしかしていませんが、CodeBuildでもっと複雑な処理をしたい場合はこの3分間はちょっと辛そうです。

終わりに

あとは実際に CodeBuildのリソースを作成して実地確認ですかねー。
CodeBuild artifactはS3にアップロードされるので、それをフックに 前回調査 したAmplifyのマニュアルビルドを起動してあげれば、CodePipelineからのAmplifyデプロイが構築できそうです。

楽しみですね！

AWS CodeBuildのローカル実行


はじめに

こんにちは。年に一度は必ず『惑星のさみだれ』を読み返してそのたびに感涙している小木（@jacoyutorius）です。

私の所属する開発チームでは今後開発する施主さん向けの新機能について、Figmaでデザインされたコンポーネントとのシームレスな連携を重視して Reactで実装する方針となりました。

そして、そのReactアプリケーションをデプロイするのには AWS Amplify を使うことを検討しています。

AWS Amplifyとは？

AWS版の NetlifyやVercel といえば早いでしょうか。フロントエンドWebアプリケーションを一撃でデプロイできる仕組みです。
デプロイだけでなく、ファイルアップロード や ユーザー認証、地図など、AWSのサービスを簡単にアプリケーションへ組み込むためのライブラリが豊富に提供されています。

Amplifyの手動デプロイについて

Amplifyの一般的な設定では、Githubリポジトリと接続し、リポジトリへのpushをフックすることで AmplifyによるCI/CDを実行します。
本番用ブランチにプルリクエストをマージすると本番環境が自動的に更新される、という感じですね。

これ自体はとても便利な機能なのですが、私たちの場合、本番用ブランチをstaging 環境へデプロイし、その後に人手による承認ステージを経てから本番環境にデプロイする、というCodePipelineの仕組みが既に運用されているため、Amplifyのこの便利な機能が逆に邪魔になってしまうのでした。

ということで、今回はAmplifyをGithubリポジトリと接続するのではなく、手動デプロイオプションを利用することで既存のデプロイパイプラインに組み込めないか？と思い立ち調査してみました。

検証用のReactアプリをビルド

まず検証用のアプリをビルドします。

手元に AWSが先日公開したCloudscape (https://cloudscape.design/) をざっくり組み込んだだけの Reactアプリがあったのでそれを使っています。

$ yarn build
yarn run v1.22.10
$ react-scripts build
Creating an optimized production build...

File sizes after gzip:

  82.61 kB  build/static/js/main.caa05ebb.js
  31.86 kB  build/static/css/main.d2a0b07d.css

The project was built assuming it is hosted at /.
You can control this with the homepage field in your package.json.

The build folder is ready to be deployed.
You may serve it with a static server:

  npm install -g serve
  serve -s build

build ディレクトリが生成されました。

$ tree build
build
├── asset-manifest.json
├── favicon.ico
├── index.html
├── logo192.png
├── logo512.png
├── manifest.json
├── robots.txt
└── static
    ├── css
    │   ├── main.d2a0b07d.css
    │   └── main.d2a0b07d.css.map
    └── js
        ├── main.caa05ebb.js
        ├── main.caa05ebb.js.LICENSE.txt
        └── main.caa05ebb.js.map

3 directories, 12 files

ドキュメント に以下のように注記されているので気をつけましょう。

zip フォルダを作成するときは、最上位フォルダではなく、ビルド出力の内容を圧縮してください。
たとえば、ビルド出力で「build」または「public」という名前のフォルダが生成される場合は、
まずそのフォルダに移動し、すべてのコンテンツを選択し、そこから圧縮します。

ソースを含むディレクトリまでzipに含まれるとデプロイに失敗するようです（Reactで言えば、build ディレクトリを除き、その配下のファイルのみが圧縮されるようにします）

$ cd build

$ zip -r cloudscape-sandbox-develop *
  adding: asset-manifest.json (deflated 61%)
  adding: favicon.ico (deflated 11%)
  adding: index.html (deflated 45%)
  adding: logo192.png (deflated 1%)
  adding: logo512.png (deflated 0%)
  adding: manifest.json (deflated 53%)
  adding: robots.txt (deflated 10%)
  adding: static/ (stored 0%)

S3にzipファイルをアップロードする

今回は手作業で全てデフォルト設定のままS3バケットを作ってzipファイルをアップロードしました。アップロード時のオプションも全てデフォルトのままです（これがいけなかった。後述します）。

S3ManagementConsoleとogiyutoMacBook-ProWorkreactjscloudscape-sandboxとAmplifyの手動デプロイ.png

Amplifyの手動デプロイ設定

AWSのマネージメントコンソールよりAWS Amplifyを開き、「新しいアプリケーション」⇒ 「ウェブアプリケーションをホスト」を選択。

以下のようなダイアログが表示されます。今回はソース管理と連携させず、手動でデプロイしたいので「Gitプロバイダーなしでデプロイ」を選択。

AWSAmplifyconsoleとAmplifyの手動デプロイ.png

アプリケーション名・環境名・バケット・zipファイル名を入力。
環境名はデプロイ後に発行されるendpointに含まれます。

AWSAmplifyconsoleとogiyutoMacBook-Pro_Workreactjscloudscape-sandboxbuildとダウンロード.png

ファイル数が少ないこともあり、数秒でデプロイに成功しました 👏

AWSAmplifyconsole.png

発行されたendpointにアクセスすると以下のように。先程入力した環境名がURLに含まれているのがわかるかと思います。

https://develop.d3uyau3xug1qwi.amplifyapp.com/
（Basic認証は test/password で通れます）

React_App.png

ちなみに手動デプロイでもBasic認証をかけることができました。

ログインとhttpsdevelopd3uyau3xug1qwiamplifyappcom.png

トラブルシューティングなど

デプロイに成功するまでに一箇所ハマったポイントがあります。

「Please enable AccessControlList on your S3 bucket before continuing」

「保存してデプロイ」ボタンを押すと以下のようなエラーメッセージが表示されました。

AWSAmplifyconsoleとogiyutoMacBook-ProWorkreactjscloudscape-sandboxとAmplifyの手動デプロイ-2.png

S3バケットのACLが無効になっているのが原因のようです。S3バケットをデフォルト値のまま作ったため、ACLが無効になっていたのでしょう。

ACLを有効化してから再度デプロイします。

jacoyutorius-amplify-manual-deploy-S3_bucket.png

jacoyutorius-amplify-manual-deploy-S3_bucket-2.png

ACLが無効になっている場合、バケット内のオブジェクトの所有者はアカウントにのみに限定されてしまいます。そうなるとAmplifyがバケットのオブジェクトを読めないのでデプロイできないのですね。

ACLがデフォルトOffなんてそんな機能あったっけ？と思ったんですが、調べたら昨年リリースされた機能のようですね。
Amazon S3 Object Ownership で、S3 内のデータのアクセス管理をシンプル化するためのアクセスコントロールリストの無効化が可能に

S3トリガーを使ったAmplifyアプリの更新

さて、S3へ圧縮したReactのソースコードをアップロードすることでAmplifyへデプロイができたわけですが、アプリケーションの更新を適用するにはどうしたらよいか？

1つはマネージメントコンソールにて、更新するファイルを指定する方法です。
初回デプロイ時と同様のダイアログからファイルのアップロード方法を選択することで、再デプロイが行われます。

AWSAmplifyconsole.png

とはいえ、毎回マネージメントコンソールを開いてデプロイするのは手間ですし、冒頭でお話したように、今回は既存のパイプラインへの組み込みを目的としています。

ということで、もう1つの方法を採ります。S3トリガーを利用して S3へのファイルアップロードをフックにAmplifyへのデプロイをすることができます。

Deploy files stored on Amazon S3, Dropbox, or your Desktop to the AWS Amplify Console

AWS SDKで以下のようなコードを実行することで Amplifyに再デプロイを指示することができるのですね。

amplify.startDeployment({
  appId,
  branchName,
  sourceUrl: s3://${Bucket}/${objectKey}
})

基本的には記事通りに Lambdaを作成して適宜必要な権限を付与することで実装できました。
強いて言えばスクリーンショットが古いので、そのまま参考にするといささか操作に迷うということでしょうか。

少し補足します。
Lambdaが作成されたあと、「設定」のタブに記載されている実行ロールのリンクをクリックすることで、このLambdaを実行するためのIAMロールの編集ページを開くことができます。

s3-amplify-console-Lambda.png

AWSLambdaBasicExecutionRole がすでに作成されているので、それに加えてS3の参照とAmplifyの実行権限を付与します。

元の記事では S3FullAccess に加え、Amplifyについてもほぼ全ての権限を与えていますが、本番運用する場合には対象リソースを指定したり付与する権限を絞ったりしたほうが良さそうです。

IAMManagementConsole.png

IAMManagementConsole.png

ともあれ、これらの設定をすることで S3へのzipファイルアップロード後に以下のように2回目のデプロイが完了したことが確認できました。

AWSAmplifyconsole.png

AWSAmplifyconsole.png

残念ながらGithubと接続した場合に使える、以前のバージョンの再デプロイ機能は使えない様子でした。S3のバージョニング機能を使えば実現できそうな気がするので、いずれ対応してほしいところですね。
（↓はGithubと接続してデプロイした別アプリのデプロイ画面です）
AWSAmplifyconsole.png

終わりに

Amplifyの手動デプロイの仕組みについてある程度理解できました。
これを踏まえて弊チームのデプロイパイプラインにAmplifyを組み込むとするとざっくり以下のようなイメージになります。

デプロイイメージ

実はAmplifyはサービスが登場したころからプライベートの開発でずっと使っており、なんならAWSで一番好きなサービスです。
思い入れが強いので逆に選択肢から外していたのですが、今回の検証で十分に本番利用に足ることがわかってきました。本番利用することでさらなる知見が得られそうで期待しています。

さて、クラッソーネではプロダクトとチームの双方をより良く改善していけるエンジニアを募集中です！
Reactが好きな方、Amplifyでガッツリサービス運用してみたいかたのご連絡お待ちしております。

https://www.crassone.co.jp/recruit/engineer/

AWS Amplifyの手動デプロイについて検証しました

<h2 id="%E5%85%A5%E7%A4%BE%E3%82%A8%E3%83%B3%E3%83%88%E3%83%AA"><a class="header-anchor-link" href="#%E5%85%A5%E7%A4%BE%E3%82%A8%E3%83%B3%E3%83%88%E3%83%AA" aria-hidden="true"></a> 入社エントリ</h2>
こんにちは。2022年2月末にクラッソーネに入社しました小木と申します。 
入社してから一月ほど経過し、そろそろ入社エントリでも書き給えと天の声が聞こえてきたのでそろそろと筆を取った次第です。
<h2 id="%E8%87%AA%E5%B7%B1%E7%B4%B9%E4%BB%8B%E3%81%AA%E3%81%A9"><a class="header-anchor-link" href="#%E8%87%AA%E5%B7%B1%E7%B4%B9%E4%BB%8B%E3%81%AA%E3%81%A9" aria-hidden="true"></a> 自己紹介など</h2>
静岡県浜松市在住のアプリケーションデベロッパーです。 
主な開発言語はRubyとJavaScriptです。Webアプリケーション開発の仕事を初めてそろそろ10年経ちます。その前はSIerで生産管理システムの開発をしていました。
プライベートの開発では Vue.js + AWS Amplifyという構成で開発をすることが多いですが、Reactにも少し興味があります。 
（先日Reactの勉強がてらこういうものを作りました。) 
<a href="https://monitorroom.jacoyutorius.net/" target="_blank" rel="nofollow noopener noreferrer">https://monitorroom.jacoyutorius.net/</a> 
正味1時間くらいしかかかっていませんがフッと思いついたアイデアをサクッと実装できると楽しいですね。サブモニターで開いてたまに眺めています。
あと、AWS Solution Architect Associate資格を持っています（今年更新...）
基本的に浜松市の自宅からリモートで作業をしています。 
リモートは前職に在籍していた2年ほど前からコロナ禍によって始まりました。通勤が無くなったのは楽なんですが全く家から出なくなってしまったので、週一日くらいはコワーキングスペースなどで仕事をしたいなぁとか考えています。
<h2 id="%E5%80%8B%E4%BA%BA%E7%9A%84%E3%81%AA%E6%B4%BB%E5%8B%95%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6"><a class="header-anchor-link" href="#%E5%80%8B%E4%BA%BA%E7%9A%84%E3%81%AA%E6%B4%BB%E5%8B%95%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6" aria-hidden="true"></a> 個人的な活動について</h2>
<a href="https://hmrb.doorkeeper.jp/" target="_blank" rel="nofollow noopener noreferrer">Hamamatsu.rb</a>、<a href="https://jawsug-hamamatsu.doorkeeper.jp/events/134501" target="_blank" rel="nofollow noopener noreferrer">JAWS-UG浜松</a>というITコミュニティのコアメンバーとしてそれぞれ月一回程度の勉強会を開催しています。 
またシビックテックの活動として地元浜松市の職員の方と連携して<a href="https://stopcovid19.code4hamamatsu.org/" target="_blank" rel="nofollow noopener noreferrer">浜松市のコロナ対策サイト</a>を構築したりしています。
シビックテック活動についてはNHKクローズアップ現代+に取材していただきました。
<iframe id="zenn-embedded__f92b187217404" src="https://embed.zenn.studio/card#zenn-embedded__f92b187217404" data-content="https%3A%2F%2Fwww.nhk.or.jp%2Fgendai%2Fcomment%2F0015%2Ftopic002.html" frameborder="0" scrolling="no" loading="lazy"></iframe><a href="https://www.nhk.or.jp/gendai/comment/0015/topic002.html" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://www.nhk.or.jp/gendai/comment/0015/topic002.html</a>
<h2 id="%E9%96%8B%E7%99%BA%E7%92%B0%E5%A2%83%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6"><a class="header-anchor-link" href="#%E9%96%8B%E7%99%BA%E7%92%B0%E5%A2%83%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6" aria-hidden="true"></a> 開発環境について</h2>
以前のクラッソーネ開発ブログで各メンバーの開発環境が載っていたので、自分の環境も紹介します。
<img src="/images/posts/entry-ogi/ogi_desc.jpg" alt="小木のデスク" />
机は流行にのってFLEXISPOTです。お昼後の眠気がひどくなる時間帯にスタンディングにして作業をしたりします。
キーボードは <a href="https://shop.yushakobo.jp/collections/keyboard/products/keyboardio-atreus-diy-kit?variant=37665513767073" target="_blank" rel="nofollow noopener noreferrer">Keybordio Atreus</a> を使っています。半年以上使っているのですが、キー配列が標準的なキーボードとだいぶ異なるのでなかなか慣れないですね。個体差かもしれませんがチャタリングもちょくちょく発生するので別の機種に乗り換えようかなと考えています。
右側に私用のMacBook Proが置いてあります。 
キーボードやトラックパッドのUSBやモニターのHDMIケーブルはUSBハブにまとめてMacに繋いでいます。仕事用 / 私用の切り替えがちょっと面倒なのとスパゲッティ感があるのでしっかりしたドッキングステーションが欲しいなと思う今日このごろです。
<img src="/images/posts/entry-ogi/ogi_desc_2.jpg" alt />
猫の手も常備しているのですが、役に立ったためしがありません。
<h2 id="%E3%83%87%E3%82%B9%E3%82%AF%E3%83%88%E3%83%83%E3%83%97%E3%81%AA%E3%81%A9"><a class="header-anchor-link" href="#%E3%83%87%E3%82%B9%E3%82%AF%E3%83%88%E3%83%83%E3%83%97%E3%81%AA%E3%81%A9" aria-hidden="true"></a> デスクトップなど</h2>
これはあんまり話題にならない気がするのですが、クラッソーネ開発チームに限らず、皆さんの開発画面を見てみたいなと思ったりします（なんなら操作している画面をみたい）
まずは自分が晒しましょう。 
これが完璧とは思っていないのですが、毎日の作業に最適化していった結果今こんな感じです。
<img src="/images/posts/entry-ogi/ogi_terminal.png" alt />
Railsのアプリケーションについて3つのターミナルを開いています。
1つ目は <code>rails server</code> を起動しているターミナル、 
2つ目は <code>rails console</code> を起動しているターミナル、 
3つ目は 作業ディレクトリを開いただけのターミナルで、これはGitの操作用です。
仮想ディスプレイの2枚めにAtomを最大化して開いています。昨今はVSCodeのユーザーが増えているようで、私もjsを書く際はVSCodeなんですが、Ruby/Railsに関してはAtomです。 
VSCodeのRubyシンタックスハイライトがイマイチなのと、AtomのGitHubプラグインに慣れているためですね。
打ち合わせ時以外は SpotifyとかAmazon Musicで音楽を流していることが多いです。 
ここ最近はヌーノ・ベッテンコートの「Population 1」または「彼氏彼女の事情　ACT1.0（サントラ）」が延々と流れています。変に気分が上下せず、60〜70％くらいのテンションが維持されるのが良いです。
<h2 id="%E3%82%AF%E3%83%A9%E3%83%83%E3%82%BD%E3%83%BC%E3%83%8D%E3%81%AE%E9%96%8B%E7%99%BA%E3%83%81%E3%83%BC%E3%83%A0%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6"><a class="header-anchor-link" href="#%E3%82%AF%E3%83%A9%E3%83%83%E3%82%BD%E3%83%BC%E3%83%8D%E3%81%AE%E9%96%8B%E7%99%BA%E3%83%81%E3%83%BC%E3%83%A0%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6" aria-hidden="true"></a> クラッソーネの開発チームについて</h2>
クラッソーネではスクラムによる開発を行っています。 
実はこれまで本格的（というとちょっと語弊があるのですが）なスクラム開発をしたことがなかったのですが、 
文字通り他のメンバーとガッチリ組んで課題に立ち向かっていく、というスタイルがとても新鮮で適度なプレッシャーもありつつ、背中を任せられる安心感もあって快適に仕事をしています。 
少しずつコミットは重ねているものの、まだまだアプリケーション全体の理解に乏しいですが、時間が解決してくれることでしょう。
クラッソーネのプロダクトは何年も試行錯誤しつつ開発が進められているので、いわゆる”負債”があったり、歴史的経緯でややわかりづらい実装になっている箇所があったりするので、 
「なんでこのメソッド呼ばれてないんですかねぇ？」とか「db:seedが遅いんですけど皆さん平気ですかねぇ？」などと偉そうに質問したりしつつ、そういう闇に改めてスポットを当てるのも新人の役割かなと思ってやっていますよ。
<h2 id="%E3%81%BE%E3%81%A8%E3%82%81"><a class="header-anchor-link" href="#%E3%81%BE%E3%81%A8%E3%82%81" aria-hidden="true"></a> まとめ</h2>
ということで、今後ともよろしくおねがいします。


入社エントリ

こんにちは。2022年2月末にクラッソーネに入社しました小木と申します。
入社してから一月ほど経過し、そろそろ入社エントリでも書き給えと天の声が聞こえてきたのでそろそろと筆を取った次第です。

自己紹介など

静岡県浜松市在住のアプリケーションデベロッパーです。
主な開発言語はRubyとJavaScriptです。Webアプリケーション開発の仕事を初めてそろそろ10年経ちます。その前はSIerで生産管理システムの開発をしていました。

プライベートの開発では Vue.js + AWS Amplifyという構成で開発をすることが多いですが、Reactにも少し興味があります。
（先日Reactの勉強がてらこういうものを作りました。)
https://monitorroom.jacoyutorius.net/
正味1時間くらいしかかかっていませんがフッと思いついたアイデアをサクッと実装できると楽しいですね。サブモニターで開いてたまに眺めています。

あと、AWS Solution Architect Associate資格を持っています（今年更新...）

基本的に浜松市の自宅からリモートで作業をしています。
リモートは前職に在籍していた2年ほど前からコロナ禍によって始まりました。通勤が無くなったのは楽なんですが全く家から出なくなってしまったので、週一日くらいはコワーキングスペースなどで仕事をしたいなぁとか考えています。

個人的な活動について

Hamamatsu.rb、JAWS-UG浜松というITコミュニティのコアメンバーとしてそれぞれ月一回程度の勉強会を開催しています。
またシビックテックの活動として地元浜松市の職員の方と連携して浜松市のコロナ対策サイトを構築したりしています。

シビックテック活動についてはNHKクローズアップ現代+に取材していただきました。

https://www.nhk.or.jp/gendai/comment/0015/topic002.html

開発環境について

以前のクラッソーネ開発ブログで各メンバーの開発環境が載っていたので、自分の環境も紹介します。

小木のデスク

机は流行にのってFLEXISPOTです。お昼後の眠気がひどくなる時間帯にスタンディングにして作業をしたりします。

キーボードは Keybordio Atreus を使っています。半年以上使っているのですが、キー配列が標準的なキーボードとだいぶ異なるのでなかなか慣れないですね。個体差かもしれませんがチャタリングもちょくちょく発生するので別の機種に乗り換えようかなと考えています。

右側に私用のMacBook Proが置いてあります。
キーボードやトラックパッドのUSBやモニターのHDMIケーブルはUSBハブにまとめてMacに繋いでいます。仕事用 / 私用の切り替えがちょっと面倒なのとスパゲッティ感があるのでしっかりしたドッキングステーションが欲しいなと思う今日このごろです。

猫の手も常備しているのですが、役に立ったためしがありません。

デスクトップなど

これはあんまり話題にならない気がするのですが、クラッソーネ開発チームに限らず、皆さんの開発画面を見てみたいなと思ったりします（なんなら操作している画面をみたい）

まずは自分が晒しましょう。
これが完璧とは思っていないのですが、毎日の作業に最適化していった結果今こんな感じです。

Railsのアプリケーションについて3つのターミナルを開いています。

1つ目は rails server を起動しているターミナル、
2つ目は rails console を起動しているターミナル、
3つ目は 作業ディレクトリを開いただけのターミナルで、これはGitの操作用です。

仮想ディスプレイの2枚めにAtomを最大化して開いています。昨今はVSCodeのユーザーが増えているようで、私もjsを書く際はVSCodeなんですが、Ruby/Railsに関してはAtomです。
VSCodeのRubyシンタックスハイライトがイマイチなのと、AtomのGitHubプラグインに慣れているためですね。

打ち合わせ時以外は SpotifyとかAmazon Musicで音楽を流していることが多いです。
ここ最近はヌーノ・ベッテンコートの「Population 1」または「彼氏彼女の事情　ACT1.0（サントラ）」が延々と流れています。変に気分が上下せず、60〜70％くらいのテンションが維持されるのが良いです。

クラッソーネの開発チームについて

クラッソーネではスクラムによる開発を行っています。
実はこれまで本格的（というとちょっと語弊があるのですが）なスクラム開発をしたことがなかったのですが、
文字通り他のメンバーとガッチリ組んで課題に立ち向かっていく、というスタイルがとても新鮮で適度なプレッシャーもありつつ、背中を任せられる安心感もあって快適に仕事をしています。
少しずつコミットは重ねているものの、まだまだアプリケーション全体の理解に乏しいですが、時間が解決してくれることでしょう。

クラッソーネのプロダクトは何年も試行錯誤しつつ開発が進められているので、いわゆる”負債”があったり、歴史的経緯でややわかりづらい実装になっている箇所があったりするので、
「なんでこのメソッド呼ばれてないんですかねぇ？」とか「db:seedが遅いんですけど皆さん平気ですかねぇ？」などと偉そうに質問したりしつつ、そういう闇に改めてスポットを当てるのも新人の役割かなと思ってやっていますよ。

まとめ

ということで、今後ともよろしくおねがいします。


クラッソーネ開発者ブログ

小木悠斗が執筆した記事

Rails7.1アプリをAWS Copilot CLIでAWS Fargateにデプロイする

AWS CodeBuildのローカル実行

AWS Amplifyの手動デプロイについて検証しました

クラッソーネに入社しました

小木 悠斗が執筆した記事

Rails7.1アプリをAWS Copilot CLIでAWS Fargateにデプロイする

AWS CodeBuildのローカル実行

AWS Amplifyの手動デプロイについて検証しました

クラッソーネに入社しました

小木悠斗が執筆した記事