DEV Community: Atsushi Miyamoto

Quit 9 to 5 to all in on building app by solo

Atsushi Miyamoto — Sun, 28 Sep 2025 07:22:43 +0000

hi all,
it’s been a while since i wrote article, this one is just a life update!

i quit my 9 to 5 job a month ago with $0 MRR, betting everything on building a profitable app as a solo founder.

this is the biggest decision of my life. i’ve worked as a software engineer for almost 4 and a half years in Japan and Canada.
It was a fun time, but i knew this was what i always wanted since becoming a software engineer.

Why I quit

i’ve always wanted to be free, not working 9 to 5 for someone else, but creating what i want.
and now, with the rise of AI, i believe it’s the best timing ever to bet on the entrepreneurial path.

What I’ve been doing for 1 month

for the past month, i’ve been focusing on building and marketing.
i’ve never done marketing before.
it’s not glamorous, but it’s all about small, consistent progress that eventually grows into something bigger.

i started posting on X daily and gained over 100 new followers.
i posted on Reddit to spread awareness of my app.
i built an anonymous chat app called "One New Friend".

so far, it has reached 1.5k installs (iOS + Android) and makes $13 MRR. honestly, this is the happiest moment ever for me.

marketing feels plain at times, but it’s also surprisingly fun.

Try my first app

you can check out my app. it’s completely free:

iOS
Android

What’s next

this journey is just beginning.

i don’t know if I’ll succeed or fail, but i’m sure the experience will be 100% worth it.
if you’re also planning to walk a similar path, let’s connect!

Product Hunt Launch 🎉

almost forgot...
i just launched my app on Product Hunt.

it’s a big competition, so if you find my app interesting, i’d really appreciate your support and vote 🙏

Happy coding!!

Implementing Authentication with Clerk in Next.js

Atsushi Miyamoto — Mon, 14 Oct 2024 08:08:07 +0000

Introduction

Hello! I'm Atsushi, a cloud engineer working at a SaaS company in Tokyo. Recently, I implemented authentication features for my personal AI chatbot project using Clerk, an authentication service. I'd like to share the insights I gained from this experience.

What is Clerk?

Clerk is a service that provides embeddable UI components, APIs, and an administrative dashboard for user authentication and management. It supports frontend frameworks like Next.js, React, and Remix.

In addition to authentication features, Clerk offers UI components that make it easy to implement sign-in and login screens. It also integrates with services like Supabase and Firebase.

Account Creation

To get started with Clerk:

Sign up at Clerk's website by clicking the "Get started" button.
After creating an account, set up your application by providing a name and clicking "Create application".

Implementing Authentication Screens

Clerk provides UI components that make it easy to implement authentication screens. This guide focuses on implementation with Next.js using the App Router.

Prerequisites

Set environment variables in .env.local:

   NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY=xxx
   CLERK_SECRET_KEY=xxx

Set up the Clerk Provider in app/layout.tsx:

   import { ClerkProvider } from '@clerk/nextjs'
   import { jaJP } from '@clerk/localizations'

   export default function RootLayout({
     children,
   }: {
     children: React.ReactNode
   }) {
     return (
       <ClerkProvider localization={jaJP}>
         <html>
           <body>
             <main>{children}</main>
           </body>
         </html>
       </ClerkProvider>
     )
   }

Implement Middleware in middleware.ts:

   import { clerkMiddleware } from '@clerk/nextjs/server'

   export default clerkMiddleware()

   export const config = {
     matcher: [
       '/((?!_next|[^?]*\\.(?:html?|css|js(?!on)|jpe?g|webp|png|gif|svg|ttf|woff2?|ico|csv|docx?|xlsx?|zip|webmanifest)).*)',
       '/(api|trpc)(.*)',
     ],
   }

Using Standard Components

Clerk provides ready-to-use components like <SignUp /> and <SignIn /> that can be easily implemented:

import { SignUp } from '@clerk/nextjs'
export default function Page() {
  return <SignUp />
}

Custom Implementation with React Hook Form

For more control over the form, you can use React Hook Form with Clerk's helpers:

Create a custom hook (useSignInForm):

   import { useSignIn } from '@clerk/nextjs'
   import { zodResolver } from '@hookform/resolvers/zod'
   import { useForm } from 'react-hook-form'
   import { z } from 'zod'

   // ... (schema and type definitions)

   export const useSignInForm = () => {
     const { isLoaded, setActive, signIn } = useSignIn()
     // ... (form setup and submit handler)
   }

Create a Form Provider:

   import { useSignInForm } from '@/hooks/sign-in/use-sign-in'
   import { FormProvider } from 'react-hook-form'

   const SignInFormProvider = ({ children }: Props) => {
     const { methods, onHandleSubmit, loading } = useSignInForm()

     return (
       <FormProvider {...methods}>
         <form onSubmit={onHandleSubmit}>{children}</form>
       </FormProvider>
     )
   }

Create the Form component:

   import { useFormContext } from 'react-hook-form'

   const LoginForm = () => {
     const {
       register,
       formState: { errors },
     } = useFormContext()
     return (
       <>
         <h2>Login</h2>
         <input {...register('email')} />
         <input {...register('password')} />
       </>
     )
   }

Implement the login page:

   import SignInFormProvider from '@/components/forms/sign-in/form-provider'
   import LoginForm from '@/components/forms/sign-in/login-form'

   const SignInPage = () => {
     return (
       <SignInFormProvider>
         <LoginForm />
         <button type="submit">Login</button>
       </SignInFormProvider>
     )
   }

Retrieving Authentication Information

To get the user ID after sign-up:

import { currentUser } from '@clerk/nextjs/server'
const user = await currentUser()
const id = user.id

Conclusion

Clerk significantly simplifies the implementation of authentication features.
Its flexibility allows for easy integration with popular tools like React Hook Form and Zod.
However, for Next.js projects, alternatives like Auth.js or Supabase's built-in authentication should also be considered depending on the use case.

References

The Journey of Abandoning Ship2Post. Dreams, Challenges, and Lessons

Atsushi Miyamoto — Sun, 21 Jan 2024 05:40:54 +0000

As a software engineer, harbors the dream of creating their own service, stepping away from the 9 to 5 grind, and achieving financial independence. That dream led me to embark on an ambitious journey with Ship2Post, a project that began in September 2023. Today, with a heavy heart, I must announce that I'm discontinuing my work on this dream project. This blog post is not just a farewell to Ship2Post but a deep dive into the reasons for its sunset and the valuable lessons I learned along the way.

The Vision of Ship2Post

Ship2Post was envisioned as a SaaS product designed to revolutionize how indie hackers market their work. The core idea was simple yet: automatically generate engaging tweets based on your GitHub commit messages or PR titles. I aimed to eliminate a significant pain point for indie hackers – the need for effective marketing to ensure their products don't end up unnoticed. The plan was to implement a subscription-based model for monetization, but sometimes, even the most well-thought-out plans encounter unforeseen challenges.

Where Did I Stumble?

The road to failure is paved with a variety of reasons, but for me, the predominant one was time. The sheer amount of time I invested in Ship2Post eventually led to exhaustion and a loss of motivation. AI-generated tweets, once a novel idea, became commonplace, diminishing the uniqueness of my service. This isn't my first rodeo – I've built and abandoned several projects for similar reasons. It's a simple yet profound realization: spending too much time can drain your passion.

The Tech Behind the Dream

In the world of startups, minimizing expenses is crucial. Here's a glimpse into the tech stack that powered Ship2Post, all within a shoestring budget of just $10, which was my only expense for testing the OpenAI API.

Frontend

Database

Supabase

Authentication

Supabase

Other

System Overview

The architecture of Ship2Post was straightforward. Users would sign up and set up a GitHub Webhook, triggering upon commits or PR merges. These events would prompt Cloudflare Workers (our serverless solution) to generate and store tweets in the Supabase database.

Reflecting on the Journey

Building Ship2Post was an odyssey that tested my limits and taught me invaluable lessons. The primary takeaway is the importance of rapid development and deployment; dwelling too long on a project can be a recipe for lost motivation. Despite my MRR (Monthly Recurring Revenue) still being at zero, I remain committed to my dream of financial freedom through my creations.

Thank you for joining me on this journey. Your support and readership mean the world to me.

P.S. I'm currently soaking up the sun in Cebu, Philippines. If you're around, let's connect and share stories over coffee! 🚀🌴

Terraform import block to import AWS route53

Atsushi Miyamoto — Sat, 13 Jan 2024 05:53:11 +0000

Write import block

Define import block to import exist route53 resource.

// import.tf
import {
  to = aws_route53_record.example
  id = "{hostedZoneId}_{recordName}_{Type}"
}

Run command

Run tf command to output config to generated_resources.tf

terraform plan -generate-config-out=generated_resources.tf

reference:

Terraform generating-configuration

Confused, Aggregate Transaction Boundaries in Domain-Driven Design

Atsushi Miyamoto — Fri, 01 Dec 2023 13:00:09 +0000

What is an Aggregate?

An aggregate is extracted as a unit to maintain invariant conditions and brings order to the operation of objects. It consists of boundaries and a root. The boundary of an aggregate defines what is included in the aggregate. The root of an aggregate is a specific object within it. All external operations on the aggregate are conducted via the aggregate root. By not exposing objects within the aggregate boundary to the outside, the invariant conditions within the aggregate are maintained.

It is reasonable to consider aggregates as units of the repository

e.g.


// aggregates
package repository

type UserRepository interface {
    Create(user entity.User) error
    Delete(userId int) error
}

Transaction Boundaries

Scope of a Transaction.

In DDD, it is ideal to consider an aggregate should be the same as a transaction boundary.

Disadvantages of spanning transactions across aggregates:

Spanning a transaction across aggregates A and B expresses the start and end of the transaction in the application layer, obscuring the consistency level of each aggregate.
Technical changes (like ORM or storage changes) necessitate modifications in the use case/domain layer, leading to fragile code.
Spanning aggregates naturally widens the transaction scope, increasing the likelihood of db locks.

e.g.

This sample code hides the creation/commit/rollback of tx in infrastructure, but is fragile due to its dependency on the db client in the use case/domain layer. It is sort of anti-pattern. will explain later.

// Infrastructure layer

func (t *TransactionRepository) Do(ctx context.Context, runner func(tx *ent.Tx) error) error {
    // Start transaction
    tx, err := t.client.Tx(t.ctx)

    if err != nil {
        return err
    }
    err = runner(tx)

    if err != nil {
        // Rollback process
        if err := tx.Rollback(); err != nil {
            return err
        }
        return err
    }

    // Commit process
    if err := tx.Commit(); err != nil {
        return err
    }
    return nil


// Usecase layer
func (u *lessonUseCase) TransactionSample(ctx context.Context) error {
    // Has dependency with db client
    err := u.TransactionRepository.Do(ctx, func(tx *ent.Tx) error {

        // Transaction processing here
        newUser, err := userRepo.create(tx, ×××)
        if err != nil {
            return err
        }
        err := userGroupRepo.create(tx, newUser, ×××)

        return nil

    })

    if err != nil {
        return err
    }

    return nil
}

In real-world project, Of course, there are many challenging cases:

e.g. Creating a User and also wanting to update a Organization etc...

Solutions

1. Merge Aggregates

If crossing aggregates with tx is problematic, merge them together (as seen in some DDD books).

Advantages:

Maintains consistency within the aggregate Disadvantages:
Larger aggregates might lead to performance issues due to increased db locks
- Merging different aggregates into one (e.g., A and B into C) complicates the code
- Application logic becomes more infrastructure-dependent. Hard to debug and loos testability.

2. Eventual Consistency

Accept temporary data breaches.

Advantages:

No need to change aggregates - Transaction boundaries remain within existing aggregates, keeping the scope narrow

Disadvantages:

Temporary loss of consistency
Implementing measures for maintaining consistency can be cumbersome
Handling failures in mid-process (e.g. queue)
- e.g. if creating a user succeeds but creating a organization fails, the user might be removed
Handling failures in recovery

3. Transaction Across Aggregates

This is an anti-pattern.

Advantages:

Maintains consistency
No need to modify aggregates

Disadvantages:

Fragile to changes
Wider transaction scope may lead to locks

Summary

This post delves into the intricacies of aggregate transaction boundaries within DDD, highlighting the balance between consistency, performance, and system design. Practical solutions and their trade-offs are discussed, providing insights for effective DDD implementation in real-world scenarios.

Honestly, I am still confused and don't know solution. It is really depends on you and your team.
Also I did not mention about modeling in this time. I think modeling is key factor to find better solution.

Happy coding!

Step-by-Step Guide. Hosting Your Application on AWS S3

Atsushi Miyamoto — Mon, 22 May 2023 05:39:39 +0000

Are you considering hosting your Next.js static web application on AWS? If so, this article is for you! In this article, I will walk you through the process of setting up AWS S3 and CloudFront for hosting your Next.js application using Terraform. Additionally, I will explain how to establish a robust CI/CD pipeline to seamlessly deploy your application to AWS. By following this step-by-step guide, you'll gain valuable insights and practical knowledge to efficiently host your Next.js application on AWS.

Motivation

Why you should consider hosting CloudFront with S3?
Because it significantly reduces latency, ensuring faster content delivery to end-users. Also, this combination can help reduce costs associated with data transfer and it enhances security measures for your content.
Setting up continuous integration and continuous deployment (CI/CD) to deploy your application becomes easier too.

What is S3?

AWS provides a storage service called S3, which allows you to store data in the form of objects within buckets. Additionally, S3 can be used to host static websites.

What is CloudFront?

CloudFront is a well-known content delivery service, often referred to as a CDN. Its primary function is to efficiently distribute your content to end-users, ensuring fast delivery. One of the main advantages of using CloudFront is that it serves content from edge locations. This means that if your content is already available at an edge location, it can be delivered to users with minimal latency. If the content is not present at an edge location, CloudFront retrieves it from the origin, which in this case would be S3.

Let's start creating CloudFront and S3 by Terraform!

There are 5 steps to deploy your application on Kubernetes with GitHub Actions and ArgoCD.

Setup AWS Provider
Create the S3 bucket
Create the CloudFront
Setup CI/CD

NOTE:
You need to set your aws credential in (~/.aws/credentials)

1. Setup AWS Provider

Configure to execute AWS by Terraform

</> provider.tf

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 4.0"
    }
  }
  required_version = ">= 1.0"
}

provider "aws" {
  region = "ap-northeast-1"
}

2. Create the S3 bucket

</> s3.tf


resource "aws_s3_bucket" "bucket" {
  bucket = test-bucket
}

resource "aws_s3_bucket_cors_configuration" "cors_config" {
  bucket = aws_s3_bucket.bucket.id

  cors_rule {
    allowed_headers = ["*"]
    allowed_methods = ["GET", "POST", "PUT", "DELETE", "HEAD"]
    allowed_origins = ["https://set-origin"]
    expose_headers  = ["ETag"]
    max_age_seconds = 3000
  }
}

resource "aws_s3_bucket_ownership_controls" "example" {
  bucket = aws_s3_bucket.bucket.id
  rule {
    object_ownership = "ObjectWriter"
  }
}

resource "aws_s3_bucket_acl" "acl" {
  depends_on = [aws_s3_bucket_ownership_controls.example]

  bucket = aws_s3_bucket.bucket.id
  acl    = "private"
}

data "aws_iam_policy_document" "policy" {
  statement {
    actions = [
      "s3:GetObject",
    ]

    resources = [
      "${aws_s3_bucket.bucket.arn}/*",
    ]

    principals {
      type        = "Service"
      identifiers = ["cloudfront.amazonaws.com"]
    }
    condition {
      test     = "StringEquals"
      variable = "aws:SourceArn"
      values   = [aws_cloudfront_distribution.this.arn]
    }
  }
}

resource "aws_s3_bucket_policy" "bucket" {
  bucket = aws_s3_bucket.bucket.id
  policy = data.aws_iam_policy_document.policy.json
}

aws_s3_bucket_cors_configuration
- To enable Cross-Origin Resource Sharing (CORS) and allow loading resources from one domain to interact with resources in a different domain.
aws_s3_bucket_acl
- Set private to disable public access.
aws_iam_policy_document
- To restrict access to only the s3:GetObject action from CloudFront and exclude other policies for content delivery.

3. Create the CloudFront

</> cloudfront.tf

resource "aws_cloudfront_origin_access_control" "origin" {
  name                              = "cf-origin-access-control"
  description                       = "access to s3 bucket"
  origin_access_control_origin_type = "s3"
  signing_behavior                  = "always"
  signing_protocol                  = "sigv4"
}

resource "aws_cloudfront_distribution" "static" {
  default_root_object = "index.html"
  enabled             = true
  price_class         = "PriceClass_200"

  origin {
    domain_name              = aws_s3_bucket.bucket.bucket_regional_domain_name
    origin_id                = "s3-bucket"
    origin_access_control_id = aws_cloudfront_origin_access_control.origin.id
  }

  default_cache_behavior {
    allowed_methods = ["DELETE", "GET", "HEAD", "OPTIONS", "PATCH", "POST", "PUT"]
    cached_methods  = ["GET", "HEAD"]

    forwarded_values {
      cookies {
        forward = "none"
      }
      query_string = "false"
    }

    max_ttl                = 86400
    min_ttl                = 0
    target_origin_id       = "s3-bucket"
    viewer_protocol_policy = "redirect-to-https"
  }

  restrictions {
    geo_restriction {
      locations        = []
      restriction_type = "none"
    }
  }

  viewer_certificate {
    cloudfront_default_certificate = true
  }
}

aws_cloudfront_origin_access_control
- Configure the origin type as S3.
aws_cloudfront_distribution
- Create a CloudFront distribution and set the origin to a previously created S3 bucket.
- To use a custom domain with CloudFront, you can configure your domain by setting it in the viewer_certificate section of your CloudFront distribution settings. In this case, you will be using the CloudFront domain for your custom domain setup.

4. Setup CI/CD

</> deploy.yaml

Creating CI/CD using GitHub Actions allows you to automate the build process and upload files to S3.

on:
  push:
    branches: [release]

permissions:
  id-token: write
  contents: read

jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [18]
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: ${{ matrix.node-version }}
          cache: yarn
      - run: yarn
      - run: yarn build
      - name: Upload artifact
        uses: actions/upload-artifact@v3
        with:
          name: build
          path: dist/
  deploy:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - name: Download artifact
        uses: actions/download-artifact@v3
        with:
          name: build
          path: dist/

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v1-node16
        with:
          role-to-assume: arn:aws:iam::${{ secrets.AWS_ACCOUNT_ID }}:role/gha-oidc-role
          aws-region: ap-northeast-1

      - name: Publish
        uses: opspresso/action-s3-sync@master
        env:
          AWS_REGION: ap-northeast-1
          FROM_PATH: dist/
          DEST_PATH: s3://bucket

      - name: Invalidate CF
        uses: chetan/invalidate-cloudfront-action@v2
        env:
          AWS_REGION: ap-northeast-1
          DISTRIBUTION: distributionId
          PATHS: /*

Upload and Download artifact
- To share data between jobs, you can utilize the actions/upload-artifact@v3 action.
Configure AWS credentials
- To configure AWS credentials based on your IAM role, you can utilize the aws-actions/configure-aws-credentials@v1-node16 action.
Publish
- To publish your built file, you can utilize the opspresso action-s3-sync@master action.
Invalidate CF
- To remove a file from CloudFront edge caches, you can utilize the chetan/invalidate-cloudfront-action@v2 action.

Conclusion

You have learned how to host and deploy your application using Terraform and GitHub Actions, taking advantage of the managed services provided by AWS such as S3 and CloudFront. With this setup, you can easily manage and scale your application without the need for manual infrastructure management. By following the steps outlined in this article, you can confidently host your application on AWS.

Happy coding!

Reference:

Amazon Simple Storage Service Documentation

Invalidating files - Amazon CloudFront

Amazon CloudFront Documentation

Sync Github issue to Jira via GitHub Actions (GHA)

Atsushi Miyamoto — Sun, 07 May 2023 13:12:31 +0000

What I built

I built action to help the OSS maintainer easily manage certain issues on Jira.

I assume most of the OSS project has a similar process to accept the issue. For instance, if the user creates a new issue then the core maintainer will check the new issue including the content, format, etc.. if the new issue is appropriate the maintainer adds a label as showing accepted.

I found the problem during this process.
Most OSS maintainers want to manage certain issues such as critical bugs using ticketing software such as Jira however managing certain issues on Jira can be a time-consuming task. Especially when the OSS is used by many developers. Because a lot of issues can be created by users.

So I create the action to sync the Github issue to Jira automatically when the maintainer is labeled to issue as accepted.

Category Submission:

Maintainer Must-Haves

App Link

https://github.com/marketplace/actions/github-issue-sync-2-jira

Screenshots

Description

This action helps to sync github issue to Jira automatically:

An example of using a this action is when a label is applied to a GitHub issue, triggering the action to automatically synchronize the issue with Jira.
A custom label can be utilized as a sync/skipping.

Feature

Sync Github issue to Jira
A custom acceptance label can be utilized as a synchronization target.
A custom synced label can be utilized as a synchronization/skipping.
By applying a custom Jira issue type to a Jira ticket, it can be utilized.

The action will first check if the labeled issue exists, then fetch the attached labels to check if the issue is already accepted by the organizer or checked already synced to Jira.
If the already attached synced label, the action will skip the whole process. Otherwise, the action will create a new Jira issue based on the Github issue and send a request to Jira to create a new Jira issue by using Jira rest API.

Basic Usage

name: Sync issues to jira
on:
  issues:
    types: [labeled]　# should be set
jobs:
  issue-sync:
    permissions:
      issues: write # should be set
    runs-on: ubuntu-latest
    steps:
      - name: Sync to Jira
        uses: atsushii/github-issue-to-jira@v1
        with:
          github-owner: github-owner
          github-repo: repository-name
          github-token: ${{ secrets.GITHUB_TOKEN }} # read/write authorized token
          jira-hostname: hostname # Your Sync dest Jira hostname
          jira-auth-token: ${{ secrets.JIRA_AUTH_TOKEN }} # Your Jira auth token
          jira-auth-email: ${{ secrets.JIRA_AUTH_EMAIL }} # email same as jira project creator
          jira-project-key: project-key # Your Sync dest Jira project name

Link to Source Code

https://github.com/atsushii/github-issue-to-jira

Permissive License

https://github.com/atsushii/github-issue-to-jira/blob/main/LICENSE

Background (What made you decide to build this particular app? What inspired you?)

As a software engineer who frequently uses Github Actions, I was inspired to create and publish my own custom action. Additionally, since I began contributing to open-source projects, I have found it to be a very rewarding experience. As a result, I wanted to alleviate the pain of OSS maintainers by leveraging technology to the fullest extent possible.

How I built it (How did you utilize GitHub Actions or GitHub Codespaces? Did you learn something new along the way? Pick up a new skill?)

I started by researching how to sync Github issues to Jira and after a few hours of consideration, I realized that Github Actions would be a good way to implement this feature. This was my first time building and releasing a custom action, and I also had no prior experience using Jira, so I had to learn how to create a token to call the Jira API. To do this, I read the Jira REST API documentation and the GitHub documentation on creating and releasing custom actions.

Throughout the process, I gained new knowledge and skills, which made the experience even more enjoyable. I always find it exciting to learn new things and improve my abilities, and I'm looking forward to continuing to develop and release new versions of my custom action.

Additional Resources/Info

I'm a Japanese developer, Let's discuss technology while eating sushi 🍣 🍣

Deploy Your Application to ECS via CI/CD with Ecspresso

Atsushi Miyamoto — Mon, 01 May 2023 00:58:04 +0000

Are you interested in deploy your application to ECS via CI/CD?
if so, ecspresso is tool for you!

What is ecspresso?

ecspresso is a tool that helping to deploy your application to ECS,
And easy to integrate it into your CI/CD easily.

ecspresso

Motivation

Why you should consider using ecspresso for the deployment of your application to ECS rather than another deployment tool?
Because ecspresso can manage your ECS resource as code. Why is that useful?
Imagine, your team deploy frequently your application and there is a moment to change ECS configuration relates to the application such as memory or CPU, etc.. If you could manage your ECS resources as code, possible to change the configuration in every deployment easily.
Just remain, this tool is for you who manage infra resources using Terraform or a tool such as CloudFormation.

Usage

Usage: ecspresso <command>

Flags:
  -h, --help                      Show context-sensitive help.
      --envfile=ENVFILE,...       environment files
      --debug                     enable debug log
      --ext-str=KEY=VALUE;...     external string values for Jsonnet
      --ext-code=KEY=VALUE;...    external code values for Jsonnet
      --config="ecspresso.yml"    config file
      --assume-role-arn=""        the ARN of the role to assume
      --option=OPTION

Commands:

  - deploy
    - deploy service
  - diff
    - show diff between task definition, service definition with current running service and task definition
  - exec
    - execute command on task
  - init --service=SERVICE
    - create configuration files from existing ECS service
  - register
    - register task definition
  - rollback
    - rollback service
  - run
    - run task
  - wait
    - wait until service stable

How to Integrate ecspresso into CI/CD?

I will explain to you step by step!

NOTE:
You need to set your aws credential (~/.aws/credentials)
Assume your ECS is already running on AWS

Install

// brew
brew install kayac/tap/ecspresso

or

// asdf
asdf plugin add ecspresso
asdf install ecspresso 2.0.0

Init to generate yml file

Import your current ECS service setting to yml file.

ecspresso init --region ap-northeast-1 --cluster your-cluster-name --service your-service-name --config ecspresso.yml

After running the above command, you can see below generated files.

- ecspresso.yml
- ecs-service-def.json
- ecs-task-def.json.

Import your tfstate

Possible to write some external resource information such as VPC, security group Id and etc...
However, it will decrease maintainability and readability. ecspresso allows to read tfstate to solve this problem!

You can set your file path to tfstate in ecspresso.yml and then able to read it inside .json file.
prefer set func_prefix.

ecspresso.yml

region: ap-northeast-1
cluster: your-cluster-name
service: your-service-name
service_definition: ecs-service-def.json
task_definition: ecs-task-def.json
timeout: "10m0s"
plugins:
  - name: tfstate
    config:
      url: s3://path-to-terraform.tfstate
    func_prefix: sg
  - name: tfstate
    config:
      url: s3://path-to-terraform.tfstate
    func_prefix: network

ecs-service-def.json

  "networkConfiguration": {
    "awsvpcConfiguration": {
      "assignPublicIp": "DISABLED",
      "securityGroups": [
        "{{ sg_tfstate `aws_security_group.service.id` }}"
      ],
      "subnets": [
        "{{ network_tfstate `aws_subnet.private['private'].id` }}",
      ]
    }
  },

Setup ci/cd

It is simple but one important thing is that most cases, want to set the latest image for ECS task so
need to set the latest image dynamically.

Look at the export IMAGE_TAG=$ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG
I define IMAGE_TAG. It will be key.
In ecs-task-def.json you can use must_env and IMAGE_TAG will dynamically load!

ecs-task-def.json

  "image": "{{ must_env `IMAGE_TAG` }}",

GitHubActions

  deploy:
    runs-on: ubuntu-latest
    timeout-minutes: 10
    steps:
      - name: checkout
        uses: actions/checkout@v3

      - name: configure aws credentials
        uses: aws-actions/configure-aws-credentials@v1-node16
        with:
          role-to-assume: arn:aws:iam::${{ secrets.AWS_ACCOUNT_ID }}:role/role
          aws-region: ap-northeast-1

      - name: login to ecr
        id: login-ecr
        uses: aws-actions/amazon-ecr-login@v1

      - uses: actions/checkout@v3
      - uses: kayac/ecspresso@v2
        with:
          version: v2.0.0 # or latest
          # version-file: .ecspresso-version

      - name: deploy
        env:
          ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
          ECR_REPOSITORY: dev
          IMAGE_TAG: api-${{ github.sha }}
        run: |
            export IMAGE_TAG=$ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG
            ecspresso deploy --config ecspresso/ecspresso.yal

Conclusion

ecspresso is helpful to manage and deploy your application to ECS.
You can manage your ECS resources as code and easy to integrate your deployment flow into CI/CD

Thank you for reading my article, Happy Coding!

Reference:

kayac/ecspresso: ecspresso is a deployment tool for Amazon ECS

K9s to managing your k8s cluster

Atsushi Miyamoto — Fri, 31 Mar 2023 03:20:43 +0000

Are you tired of managing and debugging your Kubernetes cluster? If so, K9s is a tool for you!

What is K9s?

K9s provides a terminal UI to interact with your Kubernetes clusters. You can manage your cluster easily.

Install

brew install derailed/k9s/k9s

Basic usage

exec ctx
exec pods
exec node group
exec svc
port-forwards
logs
delete resource
describe resource

Command:
  :ctx,                         list contexts
  :pods,                        list pods
  :node,                        list node
  :svc,                         list service
  y,                            show resource manifest
  d,                            kubectl describe
  ctrl-d,                       delete resource
  l,                            show logs

why use?

Based on my experience Managing Kubernetes is hard without UI. Then I found this awesome OSS. is quite helpful, It will save you time in managing and debugging your cluster.

Conclusion

This tool is quite helpful for managing and debugging your k8s!

Thank you for reading my article, Happy Coding!

Reference:

derailed/k9s: 🐶 Kubernetes CLI To Manage Your Clusters In Style!

Execute ECS task by ecsta

Atsushi Miyamoto — Thu, 16 Mar 2023 12:53:35 +0000

Are you tired of debugging when you use an ECS? If so, ecsta is a tool for you!
ecsta is to help you execute the ECS container by cmd.

What is ecsta?

ecsta is a tool that you can use to execute your ecs tasks, such as describing, listing, and even port forwarding your ecs task easily.

fujiwara/ecsta: ECS Task Assistant tool.

Features

list tasks
describe task
exec task
portforward task
stop task
trace task
logs

Usage: ecsta <command>

Flags:
  -h, --help                        Show context-sensitive help.
  -c, --cluster=STRING              ECS cluster name ($ECS_CLUSTER)
  -r, --region=STRING               AWS region ($AWS_REGION)
  -o, --output="table"              output format (table, tsv, json) ($ECSTA_OUTPUT)
  -q, --task-format-query=STRING    A jq query to format task in selector
                                    ($ECSTA_TASK_FORMAT_QUERY)

Commands:
  configure
    Create a configuration file of ecsta

  describe
    Describe tasks

  exec
    Execute a command on a task

  list
    List tasks

  logs
    Show log messages of a task

  portforward --local-port=INT --remote-port=INT
    Forward a port of a task

  stop
    Stop a task

  trace
    Trace a task

  version
    Show version

How to use?

I will show you some features

NOTE: you need to set your aws credential (~/.aws/credentials)

Install

brew install fujiwara/tap/ecsta

List task

ecsta list -c cluster-name -s service-name

|                ID                | TASKDEFINITION  | INSTANCE | LASTSTATUS | DESIREDSTATUS |         CREATEDAT         |         GROUP         |  TYPE   |
+----------------------------------+-----------------+----------+------------+---------------+
| 12e1e24342a6bddddbf148393ab6e4cf3 | task-definition:1 |          | RUNNING    | RUNNING       | 2023-03-16T00:00:00+09:00 | service:service-name | FARGATE |

Exec task

This command is wrapper of ECS Exec

ecsta exec --service=service-name --container=container-name

Enter cluster name: cluster-name
Enter task ID: 12e1e24342a6bddddbf148393ab6e4cf3

Starting session with SessionId: ecs-execute-command-0dvv124623eaaf0f
/api #

Conclusion

This tool is quite helpful to exec your ecs task!

Thank you for reading my article, Happy Coding!

Reference:

Using Amazon ECS Exec for debugging - Amazon ECS

fujiwara/ecsta: ECS Task Assistant tool.

Kubernetes CI/CD With GHA and ArgoCD

Atsushi Miyamoto — Mon, 13 Mar 2023 07:48:11 +0000

Nowadays, most companies try to implement CI/CD pipelines to deploy applications to be easier. But how to implement it?
This article shows how to implement it to deploy your application on Kubernetes with GitHub Actions and ArgoCD.
I hope it can help your deployment process easier.

Before starting, Let me explain about what is GitOps. Because I will follow this methodology.

What is GitOps?

GitOps is an operational framework that takes DevOps best practices used for application development such as version control, collaboration, compliance, and CI/CD tooling, and applies them to infrastructure automation. GitOps was first coined by Weaveworks.

Based on that I will implement like below CI/CD.

Let's start building the CI/CD!

There are 5 steps to deploy your application on Kubernetes with GitHub Actions and ArgoCD.

Build CI
1. Login to ECR
2. Build docker image and push it to ECR
3. Update manifest file in manifest file repository
4. Create PR
Prepare Manifest file
Build CD
Recap 5.

1. Build CI

The first step is building the CI by using Github Actions. yaml file should be in application source code repository.

During CI, we can do testing, building docker, push docker image to repository and update manifest file!
You must create ECR on AWS and IAM role to login and push docker image to ECR. I will omit these part in this time.

Complete GHA file is below. I will explain each step by step.

on:
  push:
    branches: [deploy/stg]

permissions:
  id-token: write
  contents: read

jobs:
  prepare:
    name: code-deploy
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          role-to-assume: ${{ secrets.IAM_ROLE }}
          aws-region: ${{ secrets.AWS_REGION }}

      - name: login to Amazon ECR
        id: ecr
        uses: aws-actions/amazon-ecr-login@v1

      - name: docker build and push
        id: build-image
        env:
          ECR_REGISTRY: ${{ steps.ecr.outputs.registry }}
          ECR_REPOSITORY: ${{ secrets.ECR_REPOSITORY }}
          IMAGE_TAG: ${{ github.sha }}
        run: |
          docker build -f ./Dockerfile -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG --target release .
          docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG
          echo "::set-output name=image::$ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG"

      - name: fetch manifest repository
        uses: actions/checkout@v3
        with:
          repository: github-organization/manifest-repository
          token: ${{ secrets.PAT }}
          path: manifest-repo
          fetch-depth: 1

      - name: update manifest file image tag
        run: |
          wget -q https://github.com/mikefarah/yq/releases/download/v4.27.5/yq_linux_amd64
          sudo mv yq_linux_amd64 /usr/local/bin/yq
          sudo chmod +x /usr/local/bin/yq
          yq e -i '.spec.template.spec.containers[0].image |= "${{ steps.build-image.outputs.image }}"' 'manifest-repo/k8s/sample/dev/deployment.yaml'

      - name: setup Repository
        working-directory: manifest-repo
        run: |
          git fetch origin main
          git config --global user.name "github-actions[bot]"
          git config --global user.email "github-actions[bot]@users.noreply.github.com"
          git remote set-url --push origin https://github.com/***/manifest-repo.git
          git checkout -b release-${{ github.sha }}

      - name: commit
        working-directory: manifest-repo
        run: |
          git add .
          git commit -m "Release bff-admin"
          git push origin HEAD
      - name: create PR
        working-directory: manifest-repo
        run: |
          gh pr create -B main -H release-${{ github.sha }} -t "deploy-${{ github.sha }}" -b ""

Login to ECR The security reason, you must avoid to pass your access key and secret key. Instead pass credential, we can use GitHub's OIDC provider in conjunction with a configured AWS IAM Identity Provider endpoint. You must create Assume role and set it to role-to-assume

      - name: configure AWS credentials
      uses: aws-actions/configure-aws-credentials@v1
      with:
        role-to-assume: ${{ secrets.IAM_ROLE }}
        aws-region: ${{ secrets.AWS_REGION }}

    - name: login to Amazon ECR
      id: ecr
      uses: aws-actions/amazon-ecr-login@v1

ref: aws-actions/configure-aws-credentials

Build docker image and push it to ECR The next step, build a docker image and push it to ECR. I prefer to import the registry name and repository name from secret. After setting these variables, run the docker command to build and push to ECR.

    - name: docker build and push
      id: build-image
      env:
        ECR_REGISTRY: ${{ steps.ecr.outputs.registry }}
        ECR_REPOSITORY: ${{ secrets.ECR_REPOSITORY }}
        IMAGE_TAG: ${{ github.sha }}
      run: |
        docker build -f ./Dockerfile -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG --target target .
        docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG
        echo "::set-output name=image::$ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG"

Update manifest file in manifest file repository After pushing the docker image, do update the manifest file to create PR to the manifest repository. Assume the manifest repository manages your k8s manifest files. At the first, fetch the latest code from the manifest repository, and after that update file using yq. We just need to update the container image to the newest image which we uploaded to ECR in the previous step.

      - name: fetch manifest repository
        uses: actions/checkout@v3
        with:
          repository: github-organization/manifest-repository
          token: ${{ secrets.PAT }}
          path: manifest-repo
          fetch-depth: 1

      - name: update manifest file image tag
        run: |
          wget -q https://github.com/mikefarah/yq/releases/download/v4.27.5/yq_linux_amd64
          sudo mv yq_linux_amd64 /usr/local/bin/yq
          sudo chmod +x /usr/local/bin/yq
          yq e -i '.spec.template.spec.containers[0].image |= "${{ steps.build-image.outputs.image }}"' 'manifest-repo/k8s/sample/dev/deployment.yaml'

Create PR After updating the manifest file, finally, create PR to trigger CD. Merging PR can be your deploy your latest code to the production environment. I use gh to create PR.

      - name: commit
      working-directory: manifest-repo
      run: |
        git add .
        git commit -m "Release bff-admin"
        git push origin HEAD
    - name: create PR
      working-directory: manifest-repo
      run: |
        gh pr create -B main -H release-${{ github.sha }} -t "deploy-${{ github.sha }}" -b ""

2. Prepare Manifest file

Prepare the manifest file in the manifest repository. It will update by CI.
Below is a sample manifest file.
You must create namespace first. This time I create deploy-test.

manifest-repository/k8s/deploy-test/deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deploy-test
  namespace: deploy-test
spec:
  selector:
    matchLabels:
      app: deploy-test
  template:
    metadata:
      labels:
        app: deploy-test
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: eks.amazonaws.com/nodegroup
                operator: In
                values:
                  - sample-ng
      containers:
        - name: deploy-test
          image: yourAccountId.dkr.ecr.yourRegion.amazonaws.com/yourRepositoryName:yourImageTag

Remember, during CI, I use yq to update the image tag. the update part is yourImageTag.
So your pod will pull the latest image from ECR after PR is merged.

    containers:
        - name: deploy-test
          image: yourAccountId.dkr.ecr.yourRegion.amazonaws.com/yourRepositoryName:yourImageTag

3. Build CD

Finally, build a CD using ArgoCD!

*You must create namespace and cluster.

The first step is to set up a GitHub access token to access the cluster to your repository.

You can type the below cmd to set your GitHub token to your cluster.
This time namespace that I set is argocd.

export GITHUB_TOKEN=<github-token>
kubectl create secret generic github-cred -n argocd \
  --from-literal url=https://github.com/${GITHUB_USER}/manifest-repository \
  --from-literal username=<github-user> \
  --from-literal password=${GITHUB_TOKEN} \
  --from-literal name=github-cred
kubectl label secret task-tool-cluster-config-cred argocd.argoproj.io/secret-type=repository -n argoc

Then write argocd manifest file.
file path is manifest-repository/k8s/deploy-test/argocd/deploy.yaml

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: deploy-test
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/${GITHUB_USER}/manifest-repository
    targetRevision: main
    path: k8s/deploy-test
  syncPolicy:
    automated:
      selfHeal: true
      prune: true
  destination:
    server: https://kubernetes.default.svc
    namespace: deploy-test

The ArgoCD will sync with the repository that you set on spec.source part.

After all setup, finally, apply it.

kubectl apply -f k8s/deploy-test/argocd/deploy.yaml

That's it!!! you are all done setting CI/CD!

4. Recap

You created an application source code repository and manifest repository.
In the source code repo, we added CI to build and push the docker image to ECR, update the manifest file, and create PR.

You can manage your deployment whether you merge PR. After merging PR, ArgoCD will sync with your newest code.
The pod will replace to newest image from ECR!

Thank you for reading my article, Happy Coding!

Reference:

Guide To GitOps

What is GitOps? | GitLab

Automate your post to dev.to by using Github Actions

Atsushi Miyamoto — Thu, 23 Feb 2023 12:22:04 +0000

I've automated dev.to posting by using GitHub Actions and golang. Also, blog content is markdown-based managing. So you can write your blog content using your favourite IDE. Hope this solution is to improve some people's productivity.

How many minutes to set up?

It might take only 5 minutes to set up your dev.to post automation.

Let's start setting up!

You can copy my template repo from my GitHub or create your original.

This time I will describe how you set up your automation posting using my template!

There are 5 steps to setup.

1. Copy template
2. Create dev.to API Key
3. Set dev.to API Key to GitHub actions secret
4. Set up GitHub actions workflow
5. Run go program to generate new blog post.
6. Write your blog post!

1. Copy template

To copy the template, go to GitHub and click Use this template button to copy a template! I recommend you create the private repository. So your blog post can be safe.

2. Create dev.to API Key

It would be best if you created your API Key to post your blog post to dev.to.

Don't worry, it is easy.

First, click your icon to open the dropdown then click settings.

After that, click the ⚡️ Extensions.

Then finally, go to bottom and generate your API Key!

3. Set dev.to API Key to GitHub actions secret

I use GitHub actions to automate posts to dev.to. So need to set dev.to API Key to GitHub actions secret.

At the first, go to your dev.to template repo on your GitHub and click Settings.
Then click Secrets and Variables > Actions. It is in the Security section.

After that click the New repository secret button.

Set DEV_TO_API_TOKEN to Name and your dev.to API Key to Secret.

4. Set up GitHub actions workflow

I use the below package for content proofing.

textlint
Prettier
Embedme

      - name: Post
        run: DEV_TO_GIT_TOKEN=${{ secrets.DEV_TO_API_TOKEN }} yarn run dev-to-git

The above step is important to post your blog to dev.to automatically.
During this step, set your secret variable to DEV_TO_GIT_TOKEN and then run dev-to-git.
dev-to-git is implemented by maxime1992

Thank you for implementing this awesome OSS.

name: Post to dev.to

on:
  push:
    branches: [ main ]
  pull_request:

jobs:
  build:
    name: Build
    if: github.event_name == 'pull_request'
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [18]
    steps:
      - name: Checkout
        uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: ${{ matrix.node-version }}
          cache: yarn
      - run: yarn

      - name: Install textlint
        run: 'yarn add -D textlint textlint-rule-common-misspellings textlint-rule-spellchecker'

      - name: Run textlint
        run: npx textlint -f checkstyle "posts/**/*.md" >> .textlint.log

      - name: Run Prettier
        run: yarn run prettier:check

      - name: Run Embedme
        run: yarn run embedme:check

  Post:
    name: Post
    if: github.ref == 'refs/heads/main' && github.event_name == 'push'
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: ${{ matrix.node-version }}
          cache: yarn
      - run: yarn

      - name: Post
        run: DEV_TO_GIT_TOKEN=${{ secrets.DEV_TO_API_TOKEN }} yarn run dev-to-git

5. Run go program to generate new blog post.

I implemented the go program to create a draft post with just one cmd.

But wait, before running the cmd, you need to set your dev.to API key to .env file.
I already prepared .env.sample file so you can just type the below cmd to create a .env file.

cp .env.sample .env

After running the above command you have to create a .env file and finally, you can add your API key to the below part of the code in your .env file.

export DEV_TO_GIT_TOKEN=

Then now you can create your blog template by running the below cmd!

You must have imported golang to your PC.

go run main.go

the prompt shows the below question. You can type the name of the article.

Enter the name of the new article:

Then, the directory is automatically created under the posts/ dir. In this case, I typed the test as a name.

And also, the dev-to-git.json was updated, program added {"id":***,"relativePathToArticle": ***}. It is necessary to manage your post.

You can manage whether your post will be a draft or public to change the published section on generated .md file.

---
title: ***
published: false
description: description
tags:
---

6. Write your blog post!

Finally, write your blog post to generate a .md file!
If need to add an image to your post, you can save image into /assets folder and then add the relative path to your post!

e.g.
![alt](https://raw.githubusercontent.com/atsushii/dev.to/master/posts/Automate-your-post-to-dev.-to-by-github-actions/assets/** 'title')

Conclusion

That's it!!
Now push your files to Github and merge them into the main branch. The CI automatically post your content!

Reference:

Manage your dev.to blog posts from a GIT repo and use continuous deployment to auto publish/update them - DEV Community