Knowledge base updates

docs/discussions/knowledge-base/227.mdx

@@ -14,14 +14,14 @@ import GitHub from "/src/components/GitHub"
 <CenterLayout>
 <span className="searchCategory">Knowledge Base</span>
 <h1>Single vs Multiple Repos for Ref Architecture</h1>
-<GitHub discussion={{"id":"D_kwDOF8slf84AO5nA","number":227,"author":{"login":"AMMullan"},"title":"Single vs Multiple Repos for Ref Architecture","body":"We've just started using the Reference Architecture and it seems very dependent on having the one repository for everything but this goes against everything that I've ever known - from my experience, repositories should be purposeful and not monolithic. Is there a way to have the Reference Architecture used with multiple repostories?","bodyHTML":"<p dir=\"auto\">We've just started using the Reference Architecture and it seems very dependent on having the one repository for everything but this goes against everything that I've ever known - from my experience, repositories should be purposeful and not monolithic. Is there a way to have the Reference Architecture used with multiple repostories?</p>","answer":{"body":"You can reorganize the reference architecture in any way you like. E.g., you can create multiple `infrastructure-live` repos and copy paste the folder and common files to the new repos to split it out.\r\n\r\nNote that migrating to multi-repo has a few gotchas that you will want to keep in mind:\r\n\r\n- `terragrunt` currently doesn't support remote dependencies. What this means is that if a `terragrunt` module depends on anothe resource (e.g., EKS depending on VPC), then you will need to make sure that the repo contains both the code for VPC and EKS so that the dependency references can work. If you want to further split off, then just be aware that you will no longer be able to use `dependency` blocks to link the two, requiring either hard coding or a look up with the AWS CLI.\r\n- `terragrunt` currently doesn't support remote includes. What this means is that depending on how you split off the `infrastructure-live` repo, you may end up with code duplication as you will no longer be able to include common values via the `_envcommon` pattern.\r\n- The current state file path is dependent on relative paths between the root `terragrunt.hcl` and the child `terragrunt.hcl`. What this means is that depending on how you split the `infrastructure-live` repo, you may inadvertently update the path of the state file. You can fix this by doing a state migration to the new path, following https://github.com/gruntwork-io/knowledge-base/discussions/229\r\n\r\nYou may also want to take a look at https://github.com/gruntwork-io/terragrunt-infrastructure-modules-example#monorepo-vs-polyrepo to understand the tradeoffs between a monorepo setup and polyrepo setup.","bodyHTML":"<p dir=\"auto\">You can reorganize the reference architecture in any way you like. E.g., you can create multiple <code class=\"notranslate\">infrastructure-live</code> repos and copy paste the folder and common files to the new repos to split it out.</p>\n<p dir=\"auto\">Note that migrating to multi-repo has a few gotchas that you will want to keep in mind:</p>\n<ul dir=\"auto\">\n<li><code class=\"notranslate\">terragrunt</code> currently doesn't support remote dependencies. What this means is that if a <code class=\"notranslate\">terragrunt</code> module depends on anothe resource (e.g., EKS depending on VPC), then you will need to make sure that the repo contains both the code for VPC and EKS so that the dependency references can work. If you want to further split off, then just be aware that you will no longer be able to use <code class=\"notranslate\">dependency</code> blocks to link the two, requiring either hard coding or a look up with the AWS CLI.</li>\n<li><code class=\"notranslate\">terragrunt</code> currently doesn't support remote includes. What this means is that depending on how you split off the <code class=\"notranslate\">infrastructure-live</code> repo, you may end up with code duplication as you will no longer be able to include common values via the <code class=\"notranslate\">_envcommon</code> pattern.</li>\n<li>The current state file path is dependent on relative paths between the root <code class=\"notranslate\">terragrunt.hcl</code> and the child <code class=\"notranslate\">terragrunt.hcl</code>. What this means is that depending on how you split the <code class=\"notranslate\">infrastructure-live</code> repo, you may inadvertently update the path of the state file. You can fix this by doing a state migration to the new path, following <a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"3906542\" data-permission-text=\"Title is private\" data-url=\"https://github.com/gruntwork-io/knowledge-base/discussions/229\" data-hovercard-type=\"discussion\" data-hovercard-url=\"/gruntwork-io/knowledge-base/discussions/229/hovercard\" href=\"https://github.com/gruntwork-io/knowledge-base/discussions/229\">#229</a></li>\n</ul>\n<p dir=\"auto\">You may also want to take a look at <a href=\"https://github.com/gruntwork-io/terragrunt-infrastructure-modules-example#monorepo-vs-polyrepo\">https://github.com/gruntwork-io/terragrunt-infrastructure-modules-example#monorepo-vs-polyrepo</a> to understand the tradeoffs between a monorepo setup and polyrepo setup.</p>"}}} />
+<GitHub discussion={{"id":"D_kwDOF8slf84AO5nA","number":227,"author":{"login":"AMMullan"},"title":"Single vs Multiple Repos for Ref Architecture","body":"We've just started using the Reference Architecture and it seems very dependent on having the one repository for everything but this goes against everything that I've ever known - from my experience, repositories should be purposeful and not monolithic. Is there a way to have the Reference Architecture used with multiple repostories?","bodyHTML":"<p dir=\"auto\">We've just started using the Reference Architecture and it seems very dependent on having the one repository for everything but this goes against everything that I've ever known - from my experience, repositories should be purposeful and not monolithic. Is there a way to have the Reference Architecture used with multiple repostories?</p>","answer":{"body":"You can reorganize the reference architecture in any way you like. E.g., you can create multiple `infrastructure-live` repos and copy paste the folder and common files to the new repos to split it out.\r\n\r\nNote that migrating to multi-repo has a few gotchas that you will want to keep in mind:\r\n\r\n- `terragrunt` currently doesn't support remote dependencies. What this means is that if a `terragrunt` module depends on anothe resource (e.g., EKS depending on VPC), then you will need to make sure that the repo contains both the code for VPC and EKS so that the dependency references can work. If you want to further split off, then just be aware that you will no longer be able to use `dependency` blocks to link the two, requiring either hard coding or a look up with the AWS CLI.\r\n- `terragrunt` currently doesn't support remote includes. What this means is that depending on how you split off the `infrastructure-live` repo, you may end up with code duplication as you will no longer be able to include common values via the `_envcommon` pattern.\r\n- The current state file path is dependent on relative paths between the root `terragrunt.hcl` and the child `terragrunt.hcl`. What this means is that depending on how you split the `infrastructure-live` repo, you may inadvertently update the path of the state file. You can fix this by doing a state migration to the new path, following https://github.com/gruntwork-io/knowledge-base/discussions/229\r\n\r\nYou may also want to take a look at https://github.com/gruntwork-io/terragrunt-infrastructure-modules-example#monorepo-vs-polyrepo to understand the tradeoffs between a monorepo setup and polyrepo setup.","bodyHTML":"<p dir=\"auto\">You can reorganize the reference architecture in any way you like. E.g., you can create multiple <code class=\"notranslate\">infrastructure-live</code> repos and copy paste the folder and common files to the new repos to split it out.</p>\n<p dir=\"auto\">Note that migrating to multi-repo has a few gotchas that you will want to keep in mind:</p>\n<ul dir=\"auto\">\n<li><code class=\"notranslate\">terragrunt</code> currently doesn't support remote dependencies. What this means is that if a <code class=\"notranslate\">terragrunt</code> module depends on anothe resource (e.g., EKS depending on VPC), then you will need to make sure that the repo contains both the code for VPC and EKS so that the dependency references can work. If you want to further split off, then just be aware that you will no longer be able to use <code class=\"notranslate\">dependency</code> blocks to link the two, requiring either hard coding or a look up with the AWS CLI.</li>\n<li><code class=\"notranslate\">terragrunt</code> currently doesn't support remote includes. What this means is that depending on how you split off the <code class=\"notranslate\">infrastructure-live</code> repo, you may end up with code duplication as you will no longer be able to include common values via the <code class=\"notranslate\">_envcommon</code> pattern.</li>\n<li>The current state file path is dependent on relative paths between the root <code class=\"notranslate\">terragrunt.hcl</code> and the child <code class=\"notranslate\">terragrunt.hcl</code>. What this means is that depending on how you split the <code class=\"notranslate\">infrastructure-live</code> repo, you may inadvertently update the path of the state file. You can fix this by doing a state migration to the new path, following <a aria-label=\"Discussion #229\" class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"3906542\" data-permission-text=\"Title is private\" data-url=\"https://github.com/gruntwork-io/knowledge-base/discussions/229\" data-hovercard-type=\"discussion\" data-hovercard-url=\"/gruntwork-io/knowledge-base/discussions/229/hovercard\" href=\"https://github.com/gruntwork-io/knowledge-base/discussions/229\">#229</a></li>\n</ul>\n<p dir=\"auto\">You may also want to take a look at <a href=\"https://github.com/gruntwork-io/terragrunt-infrastructure-modules-example#monorepo-vs-polyrepo\">https://github.com/gruntwork-io/terragrunt-infrastructure-modules-example#monorepo-vs-polyrepo</a> to understand the tradeoffs between a monorepo setup and polyrepo setup.</p>"}}} />
 
 </CenterLayout>
 
 
 <!-- ##DOCS-SOURCER-START
 {
   "sourcePlugin": "github-discussions",
-  "hash": "2c1777ed66fc2e90f59aa3ea9945de3e"
+  "hash": "912dd73865b963953e1340c6bb59ef5c"
 }
 ##DOCS-SOURCER-END -->

docs/discussions/knowledge-base/582.mdx

@@ -14,14 +14,14 @@ import GitHub from "/src/components/GitHub"
 <CenterLayout>
 <span className="searchCategory">Knowledge Base</span>
 <h1>CIDR change to reference architecture</h1>
-<GitHub discussion={{"id":"D_kwDOF8slf84ARTC0","number":582,"author":{"login":"icfai-aniketsingh"},"title":"CIDR change to reference architecture","body":"\nCurrently we had got setup the reference architecture with the default CIDR for the dev, stage and prod and we want to change those CIDR to reserved CIDR. Is that could impact to whole architecture. Also, I want to know if we are following per account per application structure in that case what CIDR range would be required for the dev, stage and prod instead of /16 range.\n\n---\n\n<ins datetime=\"2022-11-03T10:00:40Z\">\n  <p><a href=\"https://support.gruntwork.io/hc/requests/109521\">Tracked in ticket #109521</a></p>\n</ins>\n","bodyHTML":"<p dir=\"auto\">Currently we had got setup the reference architecture with the default CIDR for the dev, stage and prod and we want to change those CIDR to reserved CIDR. Is that could impact to whole architecture. Also, I want to know if we are following per account per application structure in that case what CIDR range would be required for the dev, stage and prod instead of /16 range.</p>\n<hr>\n<ins datetime=\"2022-11-03T10:00:40Z\">\n  <p dir=\"auto\"><a href=\"https://support.gruntwork.io/hc/requests/109521\" rel=\"nofollow\">Tracked in ticket #109521</a></p>\n</ins>","answer":{"body":"We answered a similar question in https://github.com/gruntwork-io/knowledge-base/discussions/600.","bodyHTML":"<p dir=\"auto\">We answered a similar question in <a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"4597686\" data-permission-text=\"Title is private\" data-url=\"https://github.com/gruntwork-io/knowledge-base/discussions/600\" data-hovercard-type=\"discussion\" data-hovercard-url=\"/gruntwork-io/knowledge-base/discussions/600/hovercard\" href=\"https://github.com/gruntwork-io/knowledge-base/discussions/600\">#600</a>.</p>"}}} />
+<GitHub discussion={{"id":"D_kwDOF8slf84ARTC0","number":582,"author":{"login":"icfai-aniketsingh"},"title":"CIDR change to reference architecture","body":"\nCurrently we had got setup the reference architecture with the default CIDR for the dev, stage and prod and we want to change those CIDR to reserved CIDR. Is that could impact to whole architecture. Also, I want to know if we are following per account per application structure in that case what CIDR range would be required for the dev, stage and prod instead of /16 range.\n\n---\n\n<ins datetime=\"2022-11-03T10:00:40Z\">\n  <p><a href=\"https://support.gruntwork.io/hc/requests/109521\">Tracked in ticket #109521</a></p>\n</ins>\n","bodyHTML":"<p dir=\"auto\">Currently we had got setup the reference architecture with the default CIDR for the dev, stage and prod and we want to change those CIDR to reserved CIDR. Is that could impact to whole architecture. Also, I want to know if we are following per account per application structure in that case what CIDR range would be required for the dev, stage and prod instead of /16 range.</p>\n<hr>\n<ins datetime=\"2022-11-03T10:00:40Z\">\n  <p dir=\"auto\"><a href=\"https://support.gruntwork.io/hc/requests/109521\" rel=\"nofollow\">Tracked in ticket #109521</a></p>\n</ins>","answer":{"body":"We answered a similar question in https://github.com/gruntwork-io/knowledge-base/discussions/600.","bodyHTML":"<p dir=\"auto\">We answered a similar question in <a aria-label=\"Discussion #600\" class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"4597686\" data-permission-text=\"Title is private\" data-url=\"https://github.com/gruntwork-io/knowledge-base/discussions/600\" data-hovercard-type=\"discussion\" data-hovercard-url=\"/gruntwork-io/knowledge-base/discussions/600/hovercard\" href=\"https://github.com/gruntwork-io/knowledge-base/discussions/600\">#600</a>.</p>"}}} />
 
 </CenterLayout>
 
 
 <!-- ##DOCS-SOURCER-START
 {
   "sourcePlugin": "github-discussions",
-  "hash": "7304376ade7e9e24d216615175dbe81a"
+  "hash": "db81864a53f819735d904a5bd40494f6"
 }
 ##DOCS-SOURCER-END -->

docs/discussions/knowledge-base/632.mdx

@@ -0,0 +1,27 @@
+---
+hide_table_of_contents: true
+hide_title: true
+custom_edit_url: null
+---
+
+import CenterLayout from "/src/components/CenterLayout"
+import GitHub from "/src/components/GitHub"
+
+<head>
+  <link rel="canonical" href="https://github.com/gruntwork-io/knowledge-base/discussions/632" />
+</head>
+
+<CenterLayout>
+<span className="searchCategory">Knowledge Base</span>
+<h1>Best-practice recommendations on authenticating to Gruntwork&apos;s codebase in my CI/CD pipelines</h1>
+<GitHub discussion={{"id":"D_kwDOF8slf84ASIKE","number":632,"author":{"login":"iangrunt"},"title":"Best-practice recommendations on authenticating to Gruntwork's codebase in my CI/CD pipelines","body":"\nSince there are many ways to do this, what is the best way to authenticate to the Gruntwork modules on GitHub.com in my CI/CD pipelines? Also, how does this impact my authentication to other module sources, such as my internal VCS? \n\n---\n\n<ins datetime=\"2023-01-12T17:14:33Z\">\n  <p><a href=\"https://support.gruntwork.io/hc/requests/109793\">Tracked in ticket #109793</a></p>\n</ins>\n","bodyHTML":"<p dir=\"auto\">Since there are many ways to do this, what is the best way to authenticate to the Gruntwork modules on GitHub.com in my CI/CD pipelines? Also, how does this impact my authentication to other module sources, such as my internal VCS?</p>\n<hr>\n<ins datetime=\"2023-01-12T17:14:33Z\">\n  <p dir=\"auto\"><a href=\"https://support.gruntwork.io/hc/requests/109793\" rel=\"nofollow\">Tracked in ticket #109793</a></p>\n</ins>","answer":{"body":"[This Knowledge Base post](https://github.com/gruntwork-io/knowledge-base/discussions/650) discusses how ECS Deploy Runner and Gruntwork Pipelines use your GitHub Personal Access Token (PAT) securely, by storing it in AWS Secrets Manager and only fetching it into your running ECS container on a just-in-time basis, so your token only exists ephemerally in volatile memory within your running task. This is the default pattern that Gruntwork prefers to use when authenticating to your GitHub resources within your CI/CD pipelines.","bodyHTML":"<p dir=\"auto\"><a href=\"https://github.com/gruntwork-io/knowledge-base/discussions/650\" data-hovercard-type=\"discussion\" data-hovercard-url=\"/gruntwork-io/knowledge-base/discussions/650/hovercard\">This Knowledge Base post</a> discusses how ECS Deploy Runner and Gruntwork Pipelines use your GitHub Personal Access Token (PAT) securely, by storing it in AWS Secrets Manager and only fetching it into your running ECS container on a just-in-time basis, so your token only exists ephemerally in volatile memory within your running task. This is the default pattern that Gruntwork prefers to use when authenticating to your GitHub resources within your CI/CD pipelines.</p>"}}} />
+
+</CenterLayout>
+
+
+<!-- ##DOCS-SOURCER-START
+{
+  "sourcePlugin": "github-discussions",
+  "hash": "ce787aaff7e22bddba83fcc638ac5793"
+}
+##DOCS-SOURCER-END -->