#refarch (2024-10)

@Dan Miller (Cloud Posse) @Yonatan Koren

We use ArgoCD or helm deploy directly, both with helmfile. Although @Igor Rodionov would have to weigh in on the advantages of that decision

I would pick what makes the most sense to your engineering team. Kustomize is nice, but we’ve been using helmfile for so long that we tend to stick with it.

I think we should revisit this next year

Helmfile seems like it’s worth trying out to compare against. I might have a use case for some environments where Argo is not available (and doesn’t require frequent CD) and using Atmos to deploy to those environments might be a nice alternative.

I like the idea of a monochart that you guys developed, but it feels like it’s not being maintained for things like Istio https://github.com/cloudposse/charts/tree/master/incubator/monochart. Is there an open-source alternative that you’re aware of? Or is there a desire to maintain this one?

I’ve changed tact on monochart. We still standby the pattern, but instead of us managing it, we instruct customers how to create their own monochart for their organization

When we managed it, what ended up happening is we were reinventing the k8s spec after adding support for everything. Because in the end, different companies use different parts. That lead to an unwieldy chart to manage, and was antithetical to what we were trying to achieve.

The idea is that each org should define an “interface” for their apps on k8s. That interface is defined via helm charts that can be reused by teams in the org to deploy services in an idiomatic way. Don’t expose every feature of k8s, instead the one you will need.

So in your case, with istio, we have a customer doing exactly this. They have a custom “monochart” (e.g. “acme-service”), which implements all the custom resources for istio the way they need it. Then any developer can deploy their service using that chart. Just bring-your-own-dockerfile.

Thanks Erik. I’ll give this a try and see how it stacks up against plain kustomize

since kustomize can deploy helm charts, I think this might be the best of both?

(that’s coming from the POV though of a helm advocate, and I’m sure many users of kustomize would disagree)

there are many diff considerations here (e.g. VPC private vs public subnets, etc.). I’m in meetings now, will try to explain later (ping me in a few hours )

@Andriy Knysh (Cloud Posse) Ok, sure

@Andriy Knysh (Cloud Posse) Pinging you again as a reminder

@Shirisha Sudhakar Rao it all depends on your network architecture and the security nd monitoring requirements. You can have many different variations of network architecture, I’ll give you a few examples here:

• If the VPCs in the two accounts have public subnets, they already have egress to the Internet via the IGW

• If the VPCs only have private subnets, then you need to provide Internet access using any of the following:

– You can connect a Site-to_site VPN to the TGW on one side, and then add VPC attachments for the VPC on the other side of the TGW. This way, the VPN connection will provide access to the Internet. In the VPC route tables, you will have a route 0.0.0.0/0 pointing to the TGW. In the TGW route table, you will have a route 0.0.0.0/0 pointing to the VPN connection

– You can have a separate VPC (in the same or separate account, we’ll call it network). The network VPC has public subnets with a Internet Gateway (providing connection to the Internet). The VPCs in both accounts can only have private subnets. They will be connected to the Internet via the TGW and the network VPC. In this case, you will have a subnet route in each VPC 0.0.0.0/0 pointing to the TGW. In the TGW route table, you will have a route 0.0.0.0/0 pointing to the VPC attachment of the network VPC. In the network VPC, you will have a route 0.0.0.0/0 pinting to the IGW (Internet Gateway)

I suppose your question was about the last part - a network VPC with Internet access via IGW, and the other VPCs connected to the TGW and then to the network VPC

regarding this

# Use PrivateLink in private-only VPCs at least until we have
# a connection to the internet via Transit Gateway.

if both VPC are private (no public subnets), then you can use a Private Link to another VPC (e.g. network in our example), which has connection to the Internet via IGW

in all of these cases, if both VPCs are private, then you have to provide a connection to something that has Internet access

that something can be another VPC (network), and you connect the 2 VPCs to the network VPC using a Private Link, or a Transit Gateway

the TGW itself does not offer nor provide connections to the Internet, it’s just a proxy. You need to connect it to a VPC which has connection to the Internet, or to a on-site VPN (this is more complicated since it involves using on-prem equipment like Palo Alto or Cisco)

there are many different variations of the network architecture. Let me know if the above description answers your question, or you need ore help

the Cloud Posse tgw components https://github.com/cloudposse/terraform-aws-components/tree/main/modules/tgw describes the architecture where you have private VPCs in multiple accounts and also a network VPC (e.g. in a network account) which has public subnets and connection to the Internet via IGW

it’s impossible to configure all possible variations of network architectures with one terraform module. If your use case differs from the above, you will have to make adjustments in your own code