Get a Skeleton Gatsby project setup with AWS Amplify deployed to AWS Amplify Console

omenking commented 4 years ago

Gatsby has a build setup. I wonder how we can trigger a build setup with AWS Amplify Console. Right now the goal is to determine technical uncertainty between Gatsby and Amplify before adding features

rishabkumar7 commented 4 years ago

I think we can have two approaches to the CI/CD pipeline, at-least that I can think of! AWS Amplify

Deploy the Gatsby site with AWS Amplify.

AWS CodePipeline

We can use Github Repo as source
And Deploy it to S3 bucket, since the site is already live with S3 and CloudFront.

Both approach seems to work, I personally have tested the Amplify and will document it below, will do the same for CodePipeline later.

omenking commented 4 years ago

My experience with AWS Amplify Console so far is that it reduces the number of steps. I am uncertain of what other limitations there are with AWS Amplify Console. CodePipeline is nice to see detailed information.

rishabkumar7 commented 4 years ago

AWS Amplify approach

Log into the Amplify Console.

From here, under Deploy we can click GET STARTED:

Next, we’ll choose GitHub as our repository & click Next.

Then connect the mater branch of the new repo we just created & click Next:

In this view, we can review the default build settings & click Next to continue:

Finally, we can review the deployment & click Save & Deploy when we’re ready to deploy our app:

Once the deployment is successful, you should see this:

Kicking off a new build

Now that our app is deployed, let’s take it one step further. The Amplify Console will automatically watch your master branch & kick off a new build whenever new code is merged. Let’s test this out.

Open src/pages/index.js & replace the following line:

<h1>Hi people</h1>

with this:

<h1>Hi #100DaysOfCloud community</h1>

Save the file & push the changes to your master branch:

git add . git commit -m 'updated heading' git push origin master

Now, when we go back into the Amplify console we’ll see that a new build has been started:

When the build is completed & we launch the app, we should now see our new heading

rishabkumar7 commented 4 years ago

AWS CodePipeline approach

Go to CodePipeline from the console → click ‘Create pipeline’ → create pipeline name (e.g. my-website-project) → choose Service role → click ‘Next’.
Choose ‘New service role’. The Role name will be auto-filled when we type in the Pipeline name
Choose GitHub for your source → connect your GitHub and choose the right repository → choose branch → select GitHub webhooks (selected by default) → click ‘Next’.
Choose AWS CodeBuild for Build provider → click ‘create project’ (a new window will pop-up.
The buildspec.yml should look something like this:

 version: 0.2

phases:
  install:
    runtime-versions:
        nodejs: 10
    commands:
      - echo Installing Gatsby and Gatsby-CLI...
      - npm install -g gatsby
      - npm install -g gatsby-cli
  pre_build:
    commands:
      - echo Installing Node packages...
      - npm install
  build:
    commands:
      - echo Build initiated...
      - npm run build
  post_build:
    commands:
      - echo Synchronizing public directory...
      - aws s3 sync ./public/ s3://rishabkumar.ml --delete
artifacts:
  base-directory: public
  files:
    - '**/*'
  discard-paths: yes

So it will delete all files in S3 bucket → create a new directory called build-output → move all files that are in public directory to build-output directory → delete everything except build-output → move all files that are in build-output → then delete build-output.

Type in ‘Project name’ → select ‘Managed image’, then a new section will show up → choose ‘Standard’ for Runtime → choose ‘standard:2.0’ for Image → leave the rest as they are and find ‘Service role’ → select ‘Existing service role’ → find the role that we created.
Leave the rest as default. I recommend CloudWatch logs to be checked in case of a failure → click ‘Continue to CodePipeline’ → click ‘Next’.
Choose ‘Amazon S3’ for provider → make sure your Region is the same as the S3 bucket’s region → find the bucket and choose → check ‘Extract file before deploy’ → click ‘Next’.
When we make changes to our code and push to the GitHub, AWS CodePipeline will detect the change and automatically upload the code to the S3 bucket.

omenking commented 4 years ago

So for the CodePipeline is this just deploying Gatsby, so there is no AWS Amplify?

mtliendo commented 4 years ago

Love the detailed overview of each path!

@omenking Yup, with codepipeline it would remove the amplify console part, which also means we would likely want to use a more generic Gatsby starter if going that route.

A couple of notes regarding AWS Amplify in terms of using it in open source:

If just using it as ci/cd platform, the Amplify console (not the amplify cli) is a great choice
If wanting to use the amplify cli as well, it's good to keep in mind that any contributor will need an AWS account--which given that 100DaysOfCloud is also supporting Google and Azure, may be a barrier to contributors
Regarding Andrew's question on other limitations, while relatively minor, keep in mind the pricing model since we may want to have a staging/develop branch that also get updated on commit as well.

Is the intent for it to be a static site or are there serverless features (auth, api, etc) that the site will need? Just bringing it up because it may be best to discuss features of the site and let that dictate what stack is best.

omenking commented 4 years ago

Dynamic or Static

There will be dynamic components, so I think serverless will be part of the equation. We have an accompanying Git Repository that they fork that is part of the challenge and we want to pull people's progress: https://github.com/100DaysOfCloud/100DaysOfCloud

So the idea is that we can show a journey board of participants based on monitoring their repo.

There could be the utility of having IdP for Twitter or Github so adding something such as Cognito may be in the development roadmap.

Agnosticism

Making note of that barrier. I want to sit this challenge up in days, and if we go the Serverless Framework we can get some agnosticism with computing, though when it comes to databases, and authentication we're going to have to make a choice unless we sit everything up in micro-services with containers and then I see our time-line stretching and stretching.

I think for the scope of this challenge page may be better to go AWS here and we should rotate out clouds so we have more opportunities. I don't foresee this project to be the only cloud project.

Pricing

I just received a fresh round of AWS Credits, So I currently feel incentivized to host on AWS. 🙃

The cost to contributors with AWS right now is pennies, so I would say if this platform becomes more than expected we'll have to address these and migrate to an ultra cost-sensitive solution. If contributors could run an entire local environment that would mitigate any costs.

I think the general rule with Serverless is to run development workloads on the cloud because local development is not reliable, though I could be unaware of better serverless solutions.

rishabkumar7 commented 4 years ago

For now, the site is deployed via amplify! https://master.d1igfgwt2o399m.amplifyapp.com/