Updated sourced GitHub KB pages (#571)

Also update version of docs-sourcer to be able to locally run regenerate command: `yarn regenerate -p github-discussions`

Author: eak12913

docs/discussions/knowledge-base/137.mdx

@@ -10,14 +10,14 @@ import GitHub from "/src/components/GitHub"
 <CenterLayout>
 <span className="searchCategory">Knowledge Base</span>
 <h1>What are the steps to have a Ref Arch deployed?</h1>
-<GitHub discussion={{"id":"D_kwDOF8slf84AOy7W","number":203,"author":{"login":"zackproser"},"title":"What are the steps to have a Ref Arch deployed?","body":"A customer asked: \r\n> What are the general steps involved with having a Reference Architecture deployed? \r\n\r\n","bodyHTML":"<p dir=\"auto\">A customer asked:</p>\n<blockquote>\n<p dir=\"auto\">What are the general steps involved with having a Reference Architecture deployed?</p>\n</blockquote>","answer":{"body":"### 1. Purchase a Reference Architecture\r\nFirst, purchase a Reference Architecture by speaking with someone on the sales team (email info at gruntwork.io) or by [checking out on the Gruntwork website](https://gruntwork.io/pricing/). \r\n### 2. Chat with our team briefly\r\nIn general, we like to speak with all our new customers first to ensure we understand your needs. Once you speak with someone and pay for your subscription and Reference Architecture. \r\n### 3. Fill out your reference-architecture-form.yml\r\nOnce you've been onboarded as a new customer, we'll invite you to a private repository. We use this repository to perform your Reference Architecture deployment. Once your deployment is complete, the entirety of the code used to deploy your Ref Arch will be available to you in the private repo. \r\n\r\nYour private repo contains detailed instructions with screenshots and optional CLI tooling that walk you through exactly how to prepare for your Ref Arch deployment. \r\n\r\nIn order to fill out your form, you'll need to create the AWS accounts that will be used for your deployment, configure some DNS entries in Route53 and run some commands to grant Gruntwork engineers temporary access to your accounts. \r\n\r\nWe strongly recommend that you use the gruntwork command line interface (CLI) tool to make this setup process as straightforward as possible. Doing everything manually will take significantly longer and any mis-configurations made manually will increase the overall time it takes to deliver your Ref Arch. \r\n\r\n### 4. Submit your yaml form to Gruntwork\r\nOnce you've completed your setup instructions and filled out your `reference-architecture-form.yml`, you can submit a pull request containing your form changes. Notify your contact at Gruntwork that you have completed your Ref Arch form. \r\n\r\nGruntwork engineers will now run pre-flight checks on your form, which are a comprehensive suite of tests and checks that ensure your accounts are ready for deployment. If there are any errors or misconfigurations that will prevent deployment, a Gruntwork engineer will let you know and ask you to make changes to your accounts and or form until the pre-flight checks all pass. \r\n\r\n### 5. Wait about a day for your deployment\r\nOnce your form is complete and all your pre-flight checks pass, you are ready for your deployment! A Grunt will let you know when everything is ready. Deployments usually take about a day once all pre-flight checks are passing. Note that, occasionally, due to either changes on AWS's side, such as resource quotas, or bugs, deployments may take longer than a full business day. The Gruntwork engineer who is deploying your Ref Arch will keep you up to date with their progress as they go. As soon as your deployment is complete, a Gruntwork engineer will let you know and point you toward the comprehensive getting started documentation that comes with your Reference Architecture deployment. ","bodyHTML":"<h3 dir=\"auto\">1. Purchase a Reference Architecture</h3>\n<p dir=\"auto\">First, purchase a Reference Architecture by speaking with someone on the sales team (email info at gruntwork.io) or by <a href=\"https://gruntwork.io/pricing/\" rel=\"nofollow\">checking out on the Gruntwork website</a>.</p>\n<h3 dir=\"auto\">2. Chat with our team briefly</h3>\n<p dir=\"auto\">In general, we like to speak with all our new customers first to ensure we understand your needs. Once you speak with someone and pay for your subscription and Reference Architecture.</p>\n<h3 dir=\"auto\">3. Fill out your reference-architecture-form.yml</h3>\n<p dir=\"auto\">Once you've been onboarded as a new customer, we'll invite you to a private repository. We use this repository to perform your Reference Architecture deployment. Once your deployment is complete, the entirety of the code used to deploy your Ref Arch will be available to you in the private repo.</p>\n<p dir=\"auto\">Your private repo contains detailed instructions with screenshots and optional CLI tooling that walk you through exactly how to prepare for your Ref Arch deployment.</p>\n<p dir=\"auto\">In order to fill out your form, you'll need to create the AWS accounts that will be used for your deployment, configure some DNS entries in Route53 and run some commands to grant Gruntwork engineers temporary access to your accounts.</p>\n<p dir=\"auto\">We strongly recommend that you use the gruntwork command line interface (CLI) tool to make this setup process as straightforward as possible. Doing everything manually will take significantly longer and any mis-configurations made manually will increase the overall time it takes to deliver your Ref Arch.</p>\n<h3 dir=\"auto\">4. Submit your yaml form to Gruntwork</h3>\n<p dir=\"auto\">Once you've completed your setup instructions and filled out your <code class=\"notranslate\">reference-architecture-form.yml</code>, you can submit a pull request containing your form changes. Notify your contact at Gruntwork that you have completed your Ref Arch form.</p>\n<p dir=\"auto\">Gruntwork engineers will now run pre-flight checks on your form, which are a comprehensive suite of tests and checks that ensure your accounts are ready for deployment. If there are any errors or misconfigurations that will prevent deployment, a Gruntwork engineer will let you know and ask you to make changes to your accounts and or form until the pre-flight checks all pass.</p>\n<h3 dir=\"auto\">5. Wait about a day for your deployment</h3>\n<p dir=\"auto\">Once your form is complete and all your pre-flight checks pass, you are ready for your deployment! A Grunt will let you know when everything is ready. Deployments usually take about a day once all pre-flight checks are passing. Note that, occasionally, due to either changes on AWS's side, such as resource quotas, or bugs, deployments may take longer than a full business day. The Gruntwork engineer who is deploying your Ref Arch will keep you up to date with their progress as they go. As soon as your deployment is complete, a Gruntwork engineer will let you know and point you toward the comprehensive getting started documentation that comes with your Reference Architecture deployment.</p>"}}} />
+<GitHub discussion={{"id":"D_kwDOF8slf84AOy7W","number":203,"author":{"login":"zackproser"},"title":"What are the steps to have a Ref Arch deployed?","body":"A customer asked: \r\n> What are the general steps involved with having a Reference Architecture deployed? \r\n\r\n","bodyHTML":"<p dir=\"auto\">A customer asked:</p>\n<blockquote>\n<p dir=\"auto\">What are the general steps involved with having a Reference Architecture deployed?</p>\n</blockquote>","answer":{"body":"### 1. Purchase a Reference Architecture\r\nFirst, purchase a Reference Architecture by speaking with someone on the sales team (email info at gruntwork.io) or by [checking out on the Gruntwork website](https://gruntwork.io/pricing/). \r\n### 2. Chat with our team briefly\r\nIn general, we like to speak with all our new customers first to ensure we understand your needs. Once you speak with someone and pay for your subscription and Reference Architecture. \r\n### 3. Fill out your reference-architecture-form.yml\r\nOnce you've been onboarded as a new customer, we'll invite you to a private repository. We use this repository to perform your Reference Architecture deployment. Once your deployment is complete, the entirety of the code used to deploy your Ref Arch will be available to you in the private repo. \r\n\r\nYour private repo contains detailed instructions with screenshots and optional CLI tooling that walk you through exactly how to prepare for your Ref Arch deployment. \r\n\r\nIn order to fill out your form, you'll need to create the AWS accounts that will be used for your deployment, configure some DNS entries in Route53 and run some commands to grant Gruntwork engineers temporary access to your accounts. \r\n\r\nWe strongly recommend that you use the gruntwork command line interface (CLI) tool to make this setup process as straightforward as possible. Doing everything manually will take significantly longer and any mis-configurations made manually will increase the overall time it takes to deliver your Ref Arch. \r\n\r\n### 4. Open a pull request with your reference-architecture-form.yml changes\r\nOnce you've completed your setup instructions and filled out your `reference-architecture-form.yml`, you can submit a pull request containing your form changes. Notify your contact at Gruntwork that you have completed your Ref Arch form. \r\n\r\nGruntwork engineers will now run pre-flight checks on your form, which are a comprehensive suite of tests and checks that ensure your accounts are ready for deployment. If there are any errors or misconfigurations that will prevent deployment, a Gruntwork engineer will let you know and ask you to make changes to your accounts and or form until the pre-flight checks all pass. \r\n\r\n### 5. Wait for your deployment to complete\r\nOnce your form is complete and all your pre-flight checks pass, you are ready for your deployment! A Grunt will let you know when everything is ready. \r\n\r\nOur current SLA for Ref Arch delivery is 2 weeks from the time your Pull Request containing your reference-architecture-form.yml changes passes all preflight checks, meaning there are no error annotations made on your GitHub pull request. \r\n\r\nOccasionally, due to either changes on AWS's side, such as resource quotas, or bugs, deployments may take longer than a full business day. The Gruntwork engineer who is deploying your Ref Arch will keep you up to date with their progress as they go. As soon as your deployment is complete, a Gruntwork engineer will let you know and point you toward the comprehensive getting started documentation that comes with your Reference Architecture deployment. ","bodyHTML":"<h3 dir=\"auto\">1. Purchase a Reference Architecture</h3>\n<p dir=\"auto\">First, purchase a Reference Architecture by speaking with someone on the sales team (email info at gruntwork.io) or by <a href=\"https://gruntwork.io/pricing/\" rel=\"nofollow\">checking out on the Gruntwork website</a>.</p>\n<h3 dir=\"auto\">2. Chat with our team briefly</h3>\n<p dir=\"auto\">In general, we like to speak with all our new customers first to ensure we understand your needs. Once you speak with someone and pay for your subscription and Reference Architecture.</p>\n<h3 dir=\"auto\">3. Fill out your reference-architecture-form.yml</h3>\n<p dir=\"auto\">Once you've been onboarded as a new customer, we'll invite you to a private repository. We use this repository to perform your Reference Architecture deployment. Once your deployment is complete, the entirety of the code used to deploy your Ref Arch will be available to you in the private repo.</p>\n<p dir=\"auto\">Your private repo contains detailed instructions with screenshots and optional CLI tooling that walk you through exactly how to prepare for your Ref Arch deployment.</p>\n<p dir=\"auto\">In order to fill out your form, you'll need to create the AWS accounts that will be used for your deployment, configure some DNS entries in Route53 and run some commands to grant Gruntwork engineers temporary access to your accounts.</p>\n<p dir=\"auto\">We strongly recommend that you use the gruntwork command line interface (CLI) tool to make this setup process as straightforward as possible. Doing everything manually will take significantly longer and any mis-configurations made manually will increase the overall time it takes to deliver your Ref Arch.</p>\n<h3 dir=\"auto\">4. Open a pull request with your reference-architecture-form.yml changes</h3>\n<p dir=\"auto\">Once you've completed your setup instructions and filled out your <code class=\"notranslate\">reference-architecture-form.yml</code>, you can submit a pull request containing your form changes. Notify your contact at Gruntwork that you have completed your Ref Arch form.</p>\n<p dir=\"auto\">Gruntwork engineers will now run pre-flight checks on your form, which are a comprehensive suite of tests and checks that ensure your accounts are ready for deployment. If there are any errors or misconfigurations that will prevent deployment, a Gruntwork engineer will let you know and ask you to make changes to your accounts and or form until the pre-flight checks all pass.</p>\n<h3 dir=\"auto\">5. Wait for your deployment to complete</h3>\n<p dir=\"auto\">Once your form is complete and all your pre-flight checks pass, you are ready for your deployment! A Grunt will let you know when everything is ready.</p>\n<p dir=\"auto\">Our current SLA for Ref Arch delivery is 2 weeks from the time your Pull Request containing your reference-architecture-form.yml changes passes all preflight checks, meaning there are no error annotations made on your GitHub pull request.</p>\n<p dir=\"auto\">Occasionally, due to either changes on AWS's side, such as resource quotas, or bugs, deployments may take longer than a full business day. The Gruntwork engineer who is deploying your Ref Arch will keep you up to date with their progress as they go. As soon as your deployment is complete, a Gruntwork engineer will let you know and point you toward the comprehensive getting started documentation that comes with your Reference Architecture deployment.</p>"}}} />
 
 </CenterLayout>
 
 
 <!-- ##DOCS-SOURCER-START
 {
   "sourcePlugin": "github-discussions",
-  "hash": "28ca72e561dfd483bc1f28ef805d40b4"
+  "hash": "599affcd72b44c330ce3c8d727564eb1"
 }
 ##DOCS-SOURCER-END -->

docs/discussions/knowledge-base/203.mdx

@@ -10,14 +10,14 @@ import GitHub from "/src/components/GitHub"
 <CenterLayout>
 <span className="searchCategory">Knowledge Base</span>
 <h1>What is the breakdown of accounts in the Ref Arch?</h1>
-<GitHub discussion={{"id":"D_kwDOF8slf84AOB0z","number":57,"author":{"login":"zackproser"},"title":"What is the breakdown of accounts in the Ref Arch?","body":"A customer asked: \r\n> Do you have one network account, which has all the VPC/DNS rules and infra defined, or do you recommend having separate dev, stage and prod accounts? \r\n\r\n","bodyHTML":"<p dir=\"auto\">A customer asked:</p>\n<blockquote>\n<p dir=\"auto\">Do you have one network account, which has all the VPC/DNS rules and infra defined, or do you recommend having separate dev, stage and prod accounts?</p>\n</blockquote>","answer":{"body":"- **Security**: for centralized authentication to other accounts, including management of IAM users, groups, and roles.\r\n- **Logs**: A log archive account that contains a central Amazon S3 bucket for storing copies of all AWS CloudTrail and AWS Config log files.\r\n- **Shared**: Shared services account for sharing resources such as Amazon Machine Images (AMIs) and Docker images with other accounts. This account can also be used to provide common infrastructure such as self-hosted CI/CD systems (e.g. Jenkins) and monitoring systems (e.g. Grafana) with other accounts.\r\n- **Dev**: A dedicated app account for development purposes, intended to isolate early development releases from the rest of your infrastructure.\r\n- **Stage**: A dedicated app account for hosting staging, testing, and/or QA environments.\r\n- **Prod**: A dedicated app account for production deployments, intended for live environments used by customers.\r\n\r\n\r\n","bodyHTML":"<ul dir=\"auto\">\n<li><strong>Security</strong>: for centralized authentication to other accounts, including management of IAM users, groups, and roles.</li>\n<li><strong>Logs</strong>: A log archive account that contains a central Amazon S3 bucket for storing copies of all AWS CloudTrail and AWS Config log files.</li>\n<li><strong>Shared</strong>: Shared services account for sharing resources such as Amazon Machine Images (AMIs) and Docker images with other accounts. This account can also be used to provide common infrastructure such as self-hosted CI/CD systems (e.g. Jenkins) and monitoring systems (e.g. Grafana) with other accounts.</li>\n<li><strong>Dev</strong>: A dedicated app account for development purposes, intended to isolate early development releases from the rest of your infrastructure.</li>\n<li><strong>Stage</strong>: A dedicated app account for hosting staging, testing, and/or QA environments.</li>\n<li><strong>Prod</strong>: A dedicated app account for production deployments, intended for live environments used by customers.</li>\n</ul>"}}} />
+<GitHub discussion={{"id":"D_kwDOF8slf84AOB0z","number":57,"author":{"login":"zackproser"},"title":"What is the breakdown of accounts in the Ref Arch?","body":"A customer asked: \r\n> Do you have one network account, which has all the VPC/DNS rules and infra defined, or do you recommend having separate dev, stage and prod accounts? \r\n\r\n","bodyHTML":"<p dir=\"auto\">A customer asked:</p>\n<blockquote>\n<p dir=\"auto\">Do you have one network account, which has all the VPC/DNS rules and infra defined, or do you recommend having separate dev, stage and prod accounts?</p>\n</blockquote>","answer":{"body":"- **Security**: for centralized authentication to other accounts, including management of IAM users, groups, and roles.\r\n- **Logs**: A log archive account that contains a central Amazon S3 bucket for storing copies of all AWS CloudTrail and AWS Config log files.\r\n- **Shared**: Shared services account for sharing resources such as Amazon Machine Images (AMIs) and Docker images with other accounts. This account can also be used to provide common infrastructure such as self-hosted CI/CD systems and monitoring systems (e.g. Grafana) with other accounts.\r\n- **Dev**: A dedicated app account for development purposes, intended to isolate early development releases from the rest of your infrastructure.\r\n- **Stage**: A dedicated app account for hosting staging, testing, and/or QA environments.\r\n- **Prod**: A dedicated app account for production deployments, intended for live environments used by customers.\r\n\r\n\r\n","bodyHTML":"<ul dir=\"auto\">\n<li><strong>Security</strong>: for centralized authentication to other accounts, including management of IAM users, groups, and roles.</li>\n<li><strong>Logs</strong>: A log archive account that contains a central Amazon S3 bucket for storing copies of all AWS CloudTrail and AWS Config log files.</li>\n<li><strong>Shared</strong>: Shared services account for sharing resources such as Amazon Machine Images (AMIs) and Docker images with other accounts. This account can also be used to provide common infrastructure such as self-hosted CI/CD systems and monitoring systems (e.g. Grafana) with other accounts.</li>\n<li><strong>Dev</strong>: A dedicated app account for development purposes, intended to isolate early development releases from the rest of your infrastructure.</li>\n<li><strong>Stage</strong>: A dedicated app account for hosting staging, testing, and/or QA environments.</li>\n<li><strong>Prod</strong>: A dedicated app account for production deployments, intended for live environments used by customers.</li>\n</ul>"}}} />
 
 </CenterLayout>
 
 
 <!-- ##DOCS-SOURCER-START
 {
   "sourcePlugin": "github-discussions",
-  "hash": "a86477a7a7530aa9b9308cad742f57a8"
+  "hash": "3a07e43ec2e990d95a1a47627383e972"
 }
 ##DOCS-SOURCER-END -->