chore(website): Refactor Files to allow Source Markdown Link Scanning (…

…#5335)

Signed-off-by: X-Guardian <[email protected]>

runatlantis.io/blog.md

@@ -11,13 +11,13 @@ We are thrilled to have you here! Our blog is a collection of insightful article
 
 We have a rich history of blog posts dating back to 2017-2019. Here are some of our popular posts:
 
-- [4 Reasons To Try HashiCorp's (New) Free Terraform Remote State Storage](/blog/2019/4-reasons-to-try-hashicorps-new-free-terraform-remote-state-storage)
-- [I'm Joining HashiCorp!](/blog/2018/joining-hashicorp)
-- [Putting The Dev Into DevOps: Why Your Developers Should Write Terraform Too](/blog/2018/putting-the-dev-into-devops-why-your-developers-should-write-terraform-too)
-- [Atlantis 0.4.4 Now Supports Bitbucket](/blog/2018/atlantis-0-4-4-now-supports-bitbucket)
-- [Terraform And The Dangers Of Applying Locally](/blog/2018/terraform-and-the-dangers-of-applying-locally)
-- [Hosting Our Static Site over SSL with S3, ACM, CloudFront and Terraform](/blog/2018/hosting-our-static-site-over-ssl-with-s3-acm-cloudfront-and-terraform)
-- [Introducing Atlantis](/blog/2017/introducing-atlantis)
+- [4 Reasons To Try HashiCorp's (New) Free Terraform Remote State Storage](blog/2019/4-reasons-to-try-hashicorps-new-free-terraform-remote-state-storage.md)
+- [I'm Joining HashiCorp!](blog/2018/joining-hashicorp.md)
+- [Putting The Dev Into DevOps: Why Your Developers Should Write Terraform Too](blog/2018/putting-the-dev-into-devops-why-your-developers-should-write-terraform-too.md)
+- [Atlantis 0.4.4 Now Supports Bitbucket](blog/2018/atlantis-0-4-4-now-supports-bitbucket.md)
+- [Terraform And The Dangers Of Applying Locally](blog/2018/terraform-and-the-dangers-of-applying-locally.md)
+- [Hosting Our Static Site over SSL with S3, ACM, CloudFront and Terraform](blog/2018/hosting-our-static-site-over-ssl-with-s3-acm-cloudfront-and-terraform.md)
+- [Introducing Atlantis](blog/2017/introducing-atlantis.md)
 
 ### Welcoming New Blog Authors
 

runatlantis.io/blog/2017/introducing-atlantis.md

@@ -17,7 +17,7 @@ functionality of Atlantis enables developers and operators to run `terraform pla
 `apply` directly from Terraform pull requests. Atlantis then comments back on the pull
 request with the output of the commands:
 
-![](/blog/intro/intro1.gif)
+![](intro/intro1.gif)
 
 This is a simple feature, however it has had a massive effect on how our team writes Terraform.
 By bringing a Terraform workflow to pull requests, Atlantis helped our Ops team collaborate
@@ -37,41 +37,41 @@ How can we enable our developers to write and apply Terraform safely?
 
 When writing Terraform, there are a number of workflows you can follow. The simplest workflow is just using `master`:
 
-![](/blog/intro/intro2.webp)
+![](intro/intro2.webp)
 
 In this workflow, you work on `master` and run `terraform` locally.
 The problem with this workflow is that there is no collaboration or code review.
 So we start to use pull requests:
 
-![](/blog/intro/intro3.webp)
+![](intro/intro3.webp)
 
 We still run `terraform plan` locally, but once we're satisfied with the changes we create a pull request for review. When the pull request is approved, we run `apply` locally.
 
 This workflow is an improvement, but there are still problems. The first problem is that it's hard to review just the diff on the pull request. To properly review a change, you really need to see the output from `terraform plan`.
 
-![](/blog/intro/intro4.webp)
+![](intro/intro4.webp)
 
 What looks like a small change...
 
-![](/blog/intro/intro5.webp)
+![](intro/intro5.webp)
 
 ...can have a big plan
 
 The second problem is that now it's easy for `master` to get out of sync with what's actually been applied. This can happen if you merge a pull request without running `apply` or if the `apply` has an error halfway through, you forget to fix it and then you merge to `master`. Now what's in `master` isn't actually what's running on production. At best, this causes confusion the next time someone runs `terraform plan`. At worst, it causes an outage when someone assumes that what's in `master` is actually running, and depends on it.
 
 With the Atlantis workflow, these problems are solved:
 
-![](/blog/intro/intro6.webp)
+![](intro/intro6.webp)
 
 Now it's easy to review changes because you see the `terraform plan` output on the pull request.
 
-![](/blog/intro/intro7.webp)
+![](intro/intro7.webp)
 
 Pull requests are easy to review since you can see the plan
 
 It's also easy to ensure that the pull request is `terraform apply`'d before merging to master because you can see the actual `apply` output on the pull request.
 
-![](/blog/intro/intro8.webp)
+![](intro/intro8.webp)
 
 So, Atlantis makes working on Terraform within an operations team much easier, but how does it help with getting your whole team to write Terraform?
 
@@ -88,7 +88,7 @@ With Atlantis, these problems are solved. All `terraform plan` and `apply` comma
 
 Since Atlantis comments back with the `plan` output directly on the pull request, it's easy for an operations engineer to review exactly what changes will be applied. And Atlantis can run in `require-approval` mode, that will require a GitHub pull request approval before allowing `apply` to be run:
 
-![](/blog/intro/intro9.webp)
+![](intro/intro9.webp)
 
 With Atlantis, developers are able to write and apply Terraform safely. They submit pull requests, can run `atlantis plan` until their change looks good and then get approval from Ops to `apply`.
 

runatlantis.io/blog/2018/atlantis-0-4-4-now-supports-bitbucket.md

@@ -11,11 +11,11 @@ This post was originally written on July 25th, 2018
 Original post: <https://medium.com/runatlantis/atlantis-0-4-4-now-supports-bitbucket-86c53a550b45>
 :::
 
-![](/blog/atlantis-0-4-4-now-supports-bitbucket/pic1.webp)
+![](atlantis-0-4-4-now-supports-bitbucket/pic1.webp)
 
 Atlantis is an [open source](https://github.com/runatlantis/atlantis) platform for using Terraform in teams. I'm happy to announce that the [latest release](https://github.com/runatlantis/atlantis/releases) of Atlantis (0.4.4) now supports both Bitbucket Cloud (bitbucket.org) **and** Bitbucket Server (aka Stash).
 
-![](/blog/atlantis-0-4-4-now-supports-bitbucket/pic2.gif)
+![](atlantis-0-4-4-now-supports-bitbucket/pic2.gif)
 
 Atlantis now supports the three major Git hosts: GitHub, GitLab and Bitbucket. The rest of this post will talk about how to use Atlantis with Bitbucket.
 
@@ -40,27 +40,27 @@ Using the web editor, open up one of your Terraform files and add:
 resource "null_resource" "example" {}
 ```
 
-![](/blog/atlantis-0-4-4-now-supports-bitbucket/pic3.webp)
+![](atlantis-0-4-4-now-supports-bitbucket/pic3.webp)
 
 Click Commit and select **Create a pull request for this change**.
 
-![](/blog/atlantis-0-4-4-now-supports-bitbucket/pic4.webp)
+![](atlantis-0-4-4-now-supports-bitbucket/pic4.webp)
 
 Wait a few seconds and then refresh. Atlantis should have automatically run `terraform plan` and commented back on the pull request:
 
-![](/blog/atlantis-0-4-4-now-supports-bitbucket/pic5.webp)
+![](atlantis-0-4-4-now-supports-bitbucket/pic5.webp)
 
 Now it's easier for your colleagues to review the pull request because they can see the `terraform plan` output.
 
 ### Terraform Apply
 
 Since all we're doing is adding a null resource, I think it's safe to run `terraform apply`. To do so, I add a comment to the pull request: `atlantis apply`:
 
-![](/blog/atlantis-0-4-4-now-supports-bitbucket/pic6.webp)
+![](atlantis-0-4-4-now-supports-bitbucket/pic6.webp)
 
 Atlantis is listening for pull request comments and will run `terraform apply` remotely and comment back with the output:
 
-![](/blog/atlantis-0-4-4-now-supports-bitbucket/pic7.webp)
+![](atlantis-0-4-4-now-supports-bitbucket/pic7.webp)
 
 ### Pull Request Approvals
 
@@ -93,7 +93,7 @@ workflows:
 
 ### Locking For Coordination
 
-![](/blog/atlantis-0-4-4-now-supports-bitbucket/pic8.webp)
+![](atlantis-0-4-4-now-supports-bitbucket/pic8.webp)
 
 Atlantis will prevent other pull requests from running against the same directory as an open pull request so that each plan is applied atomically. Once the first pull request is merged, other pull requests are unlocked.
 

runatlantis.io/blog/2018/hosting-our-static-site-over-ssl-with-s3-acm-cloudfront-and-terraform.md

@@ -28,7 +28,7 @@ NOTE: 4 months after this writing, I moved the site to [Netlify](https://www.net
 
 There's a surprising number of components required to get all this working so I'm going to start with an overview of what they're all needed for. Here's what the final architecture looks like:
 
-![](/blog/hosting-our-static-site/pic1.webp)
+![](hosting-our-static-site/pic1.webp)
 
 That's what the final product looks like, but lets start with the steps required to get there.
 
@@ -62,13 +62,13 @@ Now that we know what our architecture should look like, it's simply a matter of
 
 Create a new file `main.tf`:
 
-<<< @/public/blog/hosting-our-static-site/code/main.tf
+@include: ./publichosting-our-static-site/code/main.tf
 
 ## S3 Bucket
 
 Assuming we've generated our site content already, we need to create an S3 bucket to host the content.
 
-<<< @/public/blog/hosting-our-static-site/code/s3-bucket.tf
+@include: /publichosting-our-static-site/code/s3-bucket.tf
 
 We should be able to run Terraform now to create the S3 bucket
 
@@ -77,7 +77,7 @@ terraform init
 `terraform apply`
 ```
 
-![](/blog/hosting-our-static-site/pic2.webp)
+![](hosting-our-static-site/pic2.webp)
 
 Now we want to upload our content to the S3 bucket:
 
@@ -103,7 +103,7 @@ You should see your site hosted at that url!
 
 Let's use the AWS Certificate Manager to create our SSL certificate.
 
-<<< @/public/blog/hosting-our-static-site/code/ssl-cert.tf
+@include hosting-our-static-site/code/ssl-cert.tf
 
 Before you run `terraform apply`, ensure you're forwarding any of
 
@@ -119,7 +119,7 @@ To an email address you can access. Then, run `terraform apply` and you should g
 
 Now we're ready for CloudFront to host our website using the S3 bucket for the content and using our SSL certificate. Warning! There's a lot of code ahead but most of it is just defaults.
 
-<<< @/public/blog/hosting-our-static-site/code/cloudfront.tf
+@include: hosting-our-static-site/code/cloudfront.tf
 
 Apply the changes with `terraform apply` and then find the domain name that CloudFront gives us:
 
@@ -134,7 +134,7 @@ You'll probably get an error if you go to that URL right away. You need to wait
 
 We're almost done! We've got CloudFront hosting our site, now we need to point our DNS at it.
 
-<<< @/public/blog/hosting-our-static-site/code/dns.tf
+@include: hosting-our-static-site/code/dns.tf
 
 If you bought your domain from somewhere else like Namecheap, you'll need to point your DNS at the nameservers listed in the state for the Route53 zone you created. First `terraform apply` (which may take a while), then find out your nameservers.
 
@@ -171,4 +171,4 @@ If you're using Terraform in a team, check out Atlantis: <https://github.com/run
 
 Here's the Terraform needed to redirect your root domain:
 
-<<< @/public/blog/hosting-our-static-site/code/full.tf
+@include: hosting-our-static-site/code/full.tf

runatlantis.io/blog/2018/joining-hashicorp.md

@@ -15,7 +15,7 @@ Dear Atlantis Community,
 
 My name is Luke and I'm the maintainer of [Atlantis](https://www.runatlantis.io/), an open source tool for Terraform collaboration. Today I'm excited to announce that I'm joining HashiCorp!
 
-![](/blog/joining-hashicorp/pic1.webp)
+![](joining-hashicorp/pic1.webp)
 
 ## What Does This Mean For Atlantis?
 

runatlantis.io/blog/2018/putting-the-dev-into-devops-why-your-developers-should-write-terraform-too.md

@@ -66,7 +66,7 @@ Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
 
 Adopting Terraform is great for your operations team's effectiveness but it doesn't change much for devs. Before Terraform adoption, devs typically interacted with an ops team like this:
 
-![](/blog/putting-the-dev-into-devops/pic1.webp)
+![](putting-the-dev-into-devops/pic1.webp)
 
 1. **Dev: Creates ticket asking for some ops work**
 2. **Dev: Waits**
@@ -77,7 +77,7 @@ Adopting Terraform is great for your operations team's effectiveness but it does
 
 After the Ops team adopts Terraform, the workflow from a dev's perspective is the same!
 
-![](/blog/putting-the-dev-into-devops/pic2.webp)
+![](putting-the-dev-into-devops/pic2.webp)
 
 1. **Dev: Creates ticket asking for some ops work**
 2. **Dev: Waits**
@@ -104,7 +104,7 @@ Developers could make all of these changes because they're small and well define
 
 In many organizations, devs are locked out of the cloud console.
 
-![](/blog/putting-the-dev-into-devops/pic3.webp)
+![](putting-the-dev-into-devops/pic3.webp)
 
 They might be locked out for good reasons:
 
@@ -153,7 +153,7 @@ Devs understand code (surprise!) so it's a lot easier for them to make those sma
 
 Here's the new workflow:
 
-![](/blog/putting-the-dev-into-devops/pic4.webp)
+![](putting-the-dev-into-devops/pic4.webp)
 
 1. **Dev: Writes Terraform code**
 2. **Dev: Creates pull request**
@@ -185,37 +185,37 @@ Here's what the workflow looks like:
 
 A developer creates a pull request with their change to add a security group rule.
 
-![](/blog/putting-the-dev-into-devops/pic5.webp)
+![](putting-the-dev-into-devops/pic5.webp)
 
 ### Step 2 — Atlantis Runs Terraform Plan
 
 Atlantis automatically runs `terraform plan` and comments back on the pull request with the output. Now developers can fix their Terraform errors before asking for a review.
 
-![](/blog/putting-the-dev-into-devops/pic6.webp)
+![](putting-the-dev-into-devops/pic6.webp)
 
 ### Step 3 — Fix The Terraform
 
 The developer pushes a new commit that fixes their error and Atlantis comments back with the valid `terraform plan` output. Now the developer can verify that the plan output looks good.
 
-![](/blog/putting-the-dev-into-devops/pic7.webp)
+![](putting-the-dev-into-devops/pic7.webp)
 
 ### Step 4 — Get Approval
 
 You'll probably want to run Atlantis with the --require-approval flag that requires pull requests to be Approved before running atlantis apply.
 
-![](/blog/putting-the-dev-into-devops/pic8.webp)
+![](putting-the-dev-into-devops/pic8.webp)
 
 ### Step 4a — Actually Get Approval
 
 An operator can now come along and review the changes and the output of `terraform plan`. This is much faster than doing the change themselves.
 
-![](/blog/putting-the-dev-into-devops/pic9.webp)
+![](putting-the-dev-into-devops/pic9.webp)
 
 ### Step 5 — Apply
 
 To apply the changes, the developer or operator comments “atlantis apply”.
 
-![](/blog/putting-the-dev-into-devops/pic10.webp)
+![](putting-the-dev-into-devops/pic10.webp)
 
 ## Success
 

runatlantis.io/blog/2018/terraform-and-the-dangers-of-applying-locally.md

@@ -19,27 +19,27 @@ Here's how that tends to happen:
 
 Say we have two developers: Alice and Bob. Alice needs to add a new security group rule. She checks out a new branch, adds her rule and creates a pull request:
 
-![](/blog/terraform-and-the-dangers-of-applying-locally/pic1.webp)
+![](terraform-and-the-dangers-of-applying-locally/pic1.webp)
 
 When she runs `terraform plan` locally she sees what she expects.
 
-![](/blog/terraform-and-the-dangers-of-applying-locally/pic2.webp)
+![](terraform-and-the-dangers-of-applying-locally/pic2.webp)
 
 Meanwhile, Bob is working on an emergency fix. He checks out a new branch and adds a different security group rule called `emergency`:
 
-![](/blog/terraform-and-the-dangers-of-applying-locally/pic3.webp)
+![](terraform-and-the-dangers-of-applying-locally/pic3.webp)
 
 And, because it's an emergency, he **immediately runs apply**:
 
-![](/blog/terraform-and-the-dangers-of-applying-locally/pic4.webp)
+![](terraform-and-the-dangers-of-applying-locally/pic4.webp)
 
 Now back to Alice. She's just gotten approval on her pull request change and so she runs `terraform apply`:
 
-![](/blog/terraform-and-the-dangers-of-applying-locally/pic5.webp)
+![](terraform-and-the-dangers-of-applying-locally/pic5.webp)
 
 Did you catch what happened? Did you notice that the `apply` deleted Bob's rule?
 
-![](/blog/terraform-and-the-dangers-of-applying-locally/pic6.webp)
+![](terraform-and-the-dangers-of-applying-locally/pic6.webp)
 
 In this example, it wasn't too hard to see. However if the plan is much longer, or if the change is less obvious then it can be easy to miss.
 
@@ -51,7 +51,7 @@ There are some ways to avoid this:
 
 If Alice had run `terraform plan -out plan.tfplan` then when she ran `terraform apply plan.tfplan` she would see:
 
-![](/blog/terraform-and-the-dangers-of-applying-locally/pic7.webp)
+![](terraform-and-the-dangers-of-applying-locally/pic7.webp)
 
 The problem with this solution is that few people run `terraform plan` anymore, much less `terraform plan -out`!
 
@@ -87,21 +87,21 @@ When Alice makes her change, she creates a pull request and Atlantis automatical
 
 When Bob makes his change, he creates a pull request and Atlantis automatically runs `terraform plan` and comments on the pull request.
 
-![](/blog/terraform-and-the-dangers-of-applying-locally/pic8.webp)
+![](terraform-and-the-dangers-of-applying-locally/pic8.webp)
 
 Atlantis also **locks the directory** to ensure that no one else can run `plan` or `apply` until Alice's plan has been intentionally deleted or she merges the pull request.
 
 If Bob creates a pull request for his emergency change he'd see this error:
 
-![](/blog/terraform-and-the-dangers-of-applying-locally/pic9.webp)
+![](terraform-and-the-dangers-of-applying-locally/pic9.webp)
 
 Alice can then comment `atlantis apply` and Atlantis will run the apply itself:
 
-![](/blog/terraform-and-the-dangers-of-applying-locally/pic10.webp)
+![](terraform-and-the-dangers-of-applying-locally/pic10.webp)
 
 Finally, she merges the pull request and unlocks Bob's branch:
 
-![](/blog/terraform-and-the-dangers-of-applying-locally/pic11.webp)
+![](terraform-and-the-dangers-of-applying-locally/pic11.webp)
 
 ### But what if Bob ran `apply` locally?