<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Aws on Jason Curtis /Dev</title>
    <link>/tags/aws/</link>
    <description>Recent content in Aws on Jason Curtis /Dev</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Sun, 13 Oct 2024 23:05:24 -0500</lastBuildDate>
    <atom:link href="/tags/aws/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>CI-CD Setup Complete</title>
      <link>/posts/setup-cicd-complete/</link>
      <pubDate>Sun, 13 Oct 2024 23:05:24 -0500</pubDate>
      <guid>/posts/setup-cicd-complete/</guid>
      <description>&lt;p&gt;I haven&amp;rsquo;t worked on this site in a long time but decided to give it a refresh. In fact, I think I stopped updates mid-post last time when I was working on setting up AWS Code Build/Deploy for doing CI/CD deployments. A lot has changed since 2020 and Github Actions is amazingly powerful. That being the case I decided to retool the CI/CD on the site and immediately ran into 3+ years of technical debt. That being the NodeJS deployment of Gatsby. Gatsby was previously the tool I used to create statically generated web content. As anyone who has worked with javascript/nodejs/npm knows, you can quickly fall into a rabbit hole of resolving dependency after dependency, especially when you&amp;rsquo;re working with code no longer being maintained. This proved to be more effort than I was willing to undertake at the moment and decided to throw it all out and start over, this time without NodeJS being involved. Found several candidates for static website generatation, but one written in Go jumped out at me called Hugo. It has templating, themes, and most importantly compatible markdown formatting. Converting from Gatsby to Hugo was mostly just copying the markdown files and the general new tool learning curve. All said and down I now have Github actions doing my linting, terraform plans, and test hugo builds when pushing outside my default branch. When merging with my default branch all of the same CI kicks off, followed by terraform apply (if applicable) and hugo artifact publishing. I&amp;rsquo;m still using cloud-front as my TLS endpoint and caching service. Check out the source if you&amp;rsquo;re interested:&lt;/p&gt;</description>
    </item>
    <item>
      <title>loooong week</title>
      <link>/posts/loooong-week/</link>
      <pubDate>Thu, 02 Jul 2020 00:00:00 +0000</pubDate>
      <guid>/posts/loooong-week/</guid>
      <description>&lt;p&gt;It&amp;rsquo;s been a particular long week this week. Spent most of the week in GCP cloud training which honestly was great training. I was just slightly bored out of my mind because most of it was a compute enginer architecture course. So it was high level and I was familiar with almost all of the material already as I had spent the previous three weeks learning by doing. As part of an infrastructure team, one of our responsibilities it to provide &amp;ldquo;blessed&amp;rdquo; golden images other teams can you to deploy from, so I had already built a deployment pipeline in GCP using a combination of cloud schedule, cloud build, buckets, and compute engine. I had previously written a tool I called packer builder. It was meant to allow more flexibility by building packer templates dynamically to allow for the EXACT same automation that builds an image on vsphere, to be used in AWS, or Azure, or (in this case) GCP. Without packer builder I would have a large library of individual packer templates with duplicated code that would require tons of work updating any time I made a change to the build automation. Long story short most of my work over the last month has been around optimizing packer builder for cloud deployments and building a GCP image from scratch. With most of that out of the way and a long weekend I finally have some time to get back to my personal projects. For this site, while I technically have it deployed; updates are not automated. I started working on the buildspec required by codebuild to package up my site contents and place it on a bucket. It&amp;rsquo;s pretty simplistic but lets go over it below:&lt;/p&gt;</description>
    </item>
    <item>
      <title>Terraform Deployment</title>
      <link>/posts/terraform-deployment/</link>
      <pubDate>Sat, 27 Jun 2020 00:00:00 +0000</pubDate>
      <guid>/posts/terraform-deployment/</guid>
      <description>&lt;p&gt;Well, I decided to do some additional work on my site. Initially I was going to set the deployment up using cloudformation, but after doing some other work using terraform for another cloud provider, I just feel like terraform makes a lot more sense and decided to use that instead. For this site I&amp;rsquo;m hosting the dns zone in route53 and using cloudfront as my web frontend. Cloudfront then uses an ec2 instance as its origin server and since most of the page data is relatively static I think that should prevent the ec2 instance from taking too much traffic and falling over. I&amp;rsquo;m not likely to do any load tests though so I guess I won&amp;rsquo;t really know unless my site gets popular for some reason. I&amp;rsquo;ve also started work on the deployment pipeline. I tend to do things manually at first just to make sure I understand how I want it to be setup, then slowly replace resources with an automated deployment. So step one is to replace ec2 instance, route53 record, and cloudfront resources with versions deployed using terraform. After I&amp;rsquo;ve completed that I&amp;rsquo;ll validate my codebuild/codepipeline configuration and begin integrating these with terraform. Below is roughly what it should look like:&lt;!-- raw HTML omitted --&gt;&lt;!-- raw HTML omitted --&gt;&#xA;Enduser access:&lt;!-- raw HTML omitted --&gt;&#xA;route53 dns record -&amp;gt; cloudfront endpoint -&amp;gt; ec2 instance&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
