はてなブックマーク

TL;DR 令和に踏み台サーバーを作成する Amazon Linux 2023AMIとSSM Agentを利用したEC2 証跡を取得する About EC2とSSMのセッションロギングを使用して証跡を取得することが目的。 ECS/Fargateでも同様のことが可能ですが、SSM AgentがプリインストールされているAMIのEC2を使い捨てる方が運用コスト的や構築コスト的に楽なためEC2を選択。 How To アーキテクチャ Instance Profileの作成 assumerole.json $ cat <<EOL > assumerole.json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "ec2.amazonaws.com" }, "Action

TL;DR 「最短でプロダクションで扱うため」のコンセプトはそのままに 入門 Docker がv2になりました 5年ぶりにのアップデートで、古くなった情報を消し最新の情報の追加をしてほぼ書き直しました。 現代でも残ってしまっているような古いプラクティスについても言及しているので、再読もオススメです。 概要 入門 Docker を5年ぶりにアップデートしました。 deprecatedな部分だけは綺麗にするかと思い、git cloneしたところ筆が乗りだいぶ様変わりしてv2になりました。 変更点 古くなってしまっている情報を修正したことがメインです。 特に以下3点です。 1. DockerfileのDSL 2. compose v2対応 3. Dockerfileのベストプラクティス 他にもいくつか。 現在でも使用されている非推奨な使い方への言及 古くなってしまっているが、現在でも使用されてい

TL;DR 話題のvite を使ってReact x TypeScript のSPA を作るサンプル GitHub Pages へGitHub Actions でCD も行う vite、とても良い 概要 vite を最近良く見るので、使ってみたなど。 構築 version node 16.6.1 npm 7.20.3 vite 2.4.4 Repository https://github.com/y-ohgi/y-ohgi.github.io vite でReact の環境を構築する vite でreact のTypeScript テンプレートを指定して構築する $ npm init vite@latest aboutme -- --template react-ts $ tree aboutme/ aboutme/ |-- index.html |-- package.json |--

TL;DR つくりたいCtoC サービスがあり、法人口座がほしかったので登記した。 想定外に法人系のタスクが多く、一応一通り法人の体裁が整ったのでそのメモ 顧問税理士・弁護士・法人口座・法人カードに疲弊した 概要 CtoC のサービスを作っていて、スタートアップとして会社をしたかったというより法人口座がほしかったので登記して法人（合同会社）になった。 法人口座が欲しかった理由としては個人口座から振り込みを個人に行うのはサービスとしてありえないなと思ったためで、そこに深い理由なんてなかったし、その先のハンコと書類地獄は想像その時考えもしていなかった。 【新サービス告知】 シチュエーションボイス専門のユーザー投稿型プラットフォーム @voicheer を5月末にローンチします！ 好みのシチュエーションボイスを見つけて試聴でき、そして誰でも投稿&収益化が行える、シチュエーションボイスのためのサー

TL;DR ついに kubectl exec 的な機能がECS にもきた https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-exec.html 既存のコンテナに新しくなにかをインストールする必要はなく、SSM 経由でつかえる やる チュートリアルのとおりにやる。 https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-exec.html タスク用IAMロール作成 SSM 経由でECS へコマンドを実行するため、その権限用のIAM ロールを作成。 名前は ecsTaskRole にし、Principalは "Service": "ecs-tasks.amazonaws.com" 。 インラインポリシーで以下を定義。 { "Version": "

公式のものがみつからなかったのでDockerfile を書きました。 GitHub https://github.com/y-ohgi/dockerfiles/blob/master/firebase/Dockerfile DockerHub https://hub.docker.com/r/yohgi/firebase/dockerfile 以下で作成するDocker イメージを置いてます（主に自分用）。 Docker イメージの作成 予めFirebase のコンフィグ firebase.json を用意しておきます。 ここで立ち上げたいサービスの宣言をします。コンテナへのアクセスを受け付けるために host: "0.0.0.0" を忘れずに設定しましょう。 { "emulators": { "firestore": { "host": "0.0.0.0", "port": "8080"

TL;DR clubhouse のような複数人でのボイスチャットサービス「mixroom」をつくりました 主にSkyWay・Firebase・Next.js を使いました。 https://mixroom.fun 「mixroom」 とは mixroom は"目的ベース"でボイスチャットをする場所を提供するサービスです。 昨今は人と話す機会が減り、友好関係も自分から能動的に獲得しにいかないと減るばかりで「孤独感を感じる」みたいなことが増えてきました。 そんなとき、ふらっと立ち寄れるなんの気構えしなくて良い場所があればなと思い、このサービスを作ってみました。 ボイスチャットをするモチベーションを"特定の人"ではなく、ゲーム・実況・もくもく会などの"目的"にすることで良い意味で言い訳ができ、人とのつながりを感じることができるんじゃないかなと考えています。 気構えしなくてよい・カジュアルに参加で

概要 学生氏に適当なことを言い過ぎ反省しているので、バックエンドのいま覚えてる良かった記事の共有です。 まっさきにみるやつ Web 系エンジニアの学習ロードマップです。 とりあえずこのロードマップにのってる"紫のチェックマーク"がついたものを順番にこなしていけば良いとおもいます。backend のロードマップを紹介しましたが他にもfrontend やdevops などもあります。しかも毎年更新してくれます。 この記事はこのロードマップ以上の情報は提供できません。おわり。 roadmap.sh その他 エンジニアリングについては雑に調べると歴戦のエンジニア各位が紹介してくださってるので、クラウド系をメインに紹介します。 一般的なやつ タイトルママ。 バックエンドというよりエンジニアリング全般。 japan.googleblog.com 技術記事に特化したキュレーションサービスです。 追いたい

TL;DR NewRelic でtd-agent のメトリクス(retry, buffer, ...)を監視する方法 概要 td-agent でEC2 インスタンス内のログをS3 へ転送していまして、そのtd-agent がちゃんと動いているかをNewRelic agent で監視する方法についてです。 ※ NewRelic でロギングを行う方法についてではなく、ロギングを行っているtd-agent をNewRelic で監視する方法についてです。 方法 やることとしてはNewRelic のnri-flex 機能を使用して、td-agent のメトリクスエンドポイントのJSON をそのままNewRelic へ転送を行います。 EC2 インスタンスの準備 AmazonLinux2 を立ててセッションマネージャ経由でssh してroot ユーザーで操作します。 本番はPacker なりImag

https://blimpup.io TL;DR docker-compose をリモートで実行するための開発フェーズ向けのサービス ローカルマシンへ負荷をかけずに開発できる URL を発行してくれるため第三者への公開も可能 概要 blimpup はざっくりいうと「docker-compose をリモートで実行する」ためのサービスです。 用途としては本番環境としてではなく開発フェーズでの利用を想定されており、docker-compose を使用した開発の効率化を行ってくれます（k8s のtelepresence に近いイメージです）。 従来開発フェーズで使用していたdocker-compose をローカルで直接コンテナを動かすのではなく、blimp の提供するインフラ上で動かし、ローカルマシンに負荷をかけることなく開発が可能になります。ローカルのファイルと同期を行ってくれるためファイルの更

TL;DR Lambda がコンテナをサポートしたらしいので試してみる 動かすDocker イメージはLambda のAPI に対応させる必要があるため、今まで使用していたイメージがそのまま動くわけではない New for AWS Lambda – Container Image Support | AWS News Blog 概要 re:Invent の発表でコンテナの実行ができるようになったので、ざっくり試してみるだけの記事 ためす 失敗例 単純なAlpine イメージだと動かないらしいので失敗してみる ECR へコンテナを上げる env コマンドを実行するだけのイメージを作成 $ export ACCOUNT_ID=$(aws sts get-caller-identity --query 'Account' --output text) $ cat <<EOL | docker b

TL;DR hashicorp がリリースしたCD ツールの hashicorp/waypoint を試してみる記事 サーバーを立ち上げてデプロイx2をしてみた（感動的に楽） 個人的にECS を運用するときはまっさきに検討したいツール version waypoint v0.1.3 試す 公式のGet Started を参考にためしてみる。 https://learn.hashicorp.com/collections/waypoint/get-started-docker Install 各種OS に対応している。とりあえず今回はMacを選択。 https://learn.hashicorp.com/tutorials/waypoint/get-started-install?in=waypoint/get-started-docker brew からサクッと入る $ brew tap

概要 GKE からGCP のサービスや機能にPod 単位で権限を割り振るための機能 "Workload Identity" の概要と使い方についてです。 公式ドキュメントは以下になります。 ワークロード ID  |  Kubernetes Engine ドキュメント  |  Google Cloud Workload Identity とは WorkloadIdentity がある場合、「Pod 単位でGCP のAPI へのアクセス制御を簡易的に管理する」ことが可能です。 WorkloadIdentity を使用することでPod に対し直接GCP のServiceAccount を紐付けることができ、GCP のAPI へServiceAccount を用いたアクセス制御が可能になります。 （AWS のEKS でいうIAM roles for service accounts やkiam の

DMMグループ Advent Calendar 2019 - Qiita の25日目です TL;DR AWSで3層アーキテクチャのサービスを構築するテンプレート（ここではスターターキットと呼びます）を公開しました。 利用するコンポーネントとしては主にAWSのALB・ECS/Fargate・Aurora、Dockerとローカル環境用にdocker-compose、IaCにTerraformを利用しています。 導入や既存メンバーのためのスターターキットで使用するコンポーネントの入門用ドキュメントを備えています。 概要 y-ohgi.github.io/starterkit にgitbookとしてドキュメントを公開しているのでそちらを閲覧してください。 サンプルとしてGolang・ECS/Fargate・Aurora（MySQL）で構築をしています。 また、RailsやNextなど、コンテナベー

TL;DR 監視はユーザーにサービスを提供できているかを観測するための行為 SLI/SLOを定めて、SLOを守れるようにモニタリングする ダッシュボードは定常的に表示しておくものと障害時に活用するものを作ると良い アラートはレベル分けして人間が対応しなければならないものだけ人間へ通知する 監視とは サービスを健全に動作させ続けるために監視を行います。 「健全に動作している」の定義はサービスによって異なり、ユーザーにWebページを見せることができることだったり、バッチが正常に終了することだったりします。 最終的にユーザーに正常にサービスを提供できていることを観測するために行うことに変わりはありません。 さてユーザーにサービスを提供するために何を監視しましょうか？ クラウド前提であれば個人的にリソースベース（CPU/Memory）より、 SLI/SLOをベース に監視する事が望ましいと考えてい

この記事は DMM.com Advent Calendar 2018 - Qiita の25日目です。 About CircleCIとCode兄弟を使いCI/CDを作っていこうというものです。 単純に環境を作るわけではなく、CloudFormationを使って本番環境を想定した構成にしていきます。 ターゲットとしては既にCircleCI・CodePipelineをざっくり知っている人で、本番向けのCI/CDをどのように構築していくかについて自分なりのプラクティスを紹介します。 サンプルコード 今回の構成を再現するためのコードを用意しました。 https://github.com/y-ohgi/ci-cd-example CloudFormation 環境はCloudFormationで管理しているため以下のコマンドで再現できます。 VPC、Aurora、ECS、CodePipelineなど

概要 APIの量産が必要になったものの、複数人でAPIを量産しているとSwaggerのPRも量産されてく。 Swaggerのレビューはyamlを見てレビューするわけだけど、わざわざSwaggerのプレビューをするためにブランチにチェックアウトしてpullしてサーバー立てるのはしんどい・・・。 なんで、SwaggerリポジトリにPull Requestが立つ毎(& Commit毎)にGAEにデプロイさせて、GAEでSwaggerを確認できるようにしてレビューのフローを改善させるのがモチベーション なんでGAE GAE/SEは安い。 リクエスト毎にインスタンスが起動され、リクエストが来なくなれば一瞬で落ちる。 無料枠もある 開発メンバーで行うSwaggerのレビューレベルであれば実質タダ IP制限 Cloud Storageだと制限がかけられない問題 プロジェクトがGCPではなくAWSだったら

目次 概要 TL;DR dotfiles 実行環境 ターミナル Terminal bash .bash_profile alias/function pbcopy cdf プロンプト syslogの削除 tmux Spacemacs packages multiple-cursor undo-tree Applications Google 日本語入力 Google Chrome Chrome Extension Alfred Better Snap Tool Better Touch Tool Dropbox Postman Gyazo (GIF) Wunderlist Inkdrop Atom Visual Studio Code 概要 ローカル環境の課題として "複数環境構築時の競合" が個人的に一番つらみを感じる 下手に広く浅くWeb技術に手を出すのでフロントのツールがクラウド系の