#refarch (2024-10)
Cloud Posse Reference Architecture
2024-10-03
Do you recommend using Helmfile via ArgoCD for app deployments to EKS? Are there advantages to this approach rather than using Kustomize? (It it that it’s easier to spin up preview environments via Helmfile?)
@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)
2024-10-04
2024-10-10
2024-10-11
@Andriy Knysh (Cloud Posse)
I have used the reference architecture to setup a transit gateway to connect 2 VPCs in different accounts. However, I am having trouble understanding how the transit gateway offers a connection to the internet. Is that not a part of the reference architecture and is something we should setup separately on our own? If so, how can this be achieved?
There is a line in the reference architecture VPC section that states this
# Use PrivateLink in private-only VPCs at least until we have
# a connection to the internet via Transit Gateway.
So ideally, transit gateway setup should provide connection to the internet right?
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
@Andriy Knysh (Cloud Posse) Thank you for the information. I will try this out today.
2024-10-15
2024-10-21
2024-10-22
hi @Dan Miller (Cloud Posse) - I’d like to use the alb component to set up a 301 redirect. ex:
[test.example.com](http://test.example.com) should redirect to [app.example.com](http://app.example.com)
I can do this in the console, but I can’t figure out the syntax using the ALB component (https://github.com/cloudposse/terraform-aws-components/tree/main/modules/alb )
Is this possible to do with the current reference architecture?
rather than using alb , could you redirect your route with Route53? For example we do this with the dns-* components (https://github.com/cloudposse/terraform-aws-components/tree/main/modules/dns-primary)
see var.record_config
I tried that, but [app.example.com](http://app.example.com) is an ecs-service behind an ALB
so if I make the DNS record, it will point to the right domain, but then will hit the ALB and fail because there’s no rule to route the traffic to the correct target group
and if I use the additional_target option in the ECS service, then [test.example.com](http://test.example.com) acts as an alternate URL for [app.example.com](http://app.example.com) instead of just redirecting to the main domain
@johncblandii if I recall correctly, didnt you do something similar? Do you have any input?
I’ll have to check when I get back to Houston, but I believe we used https://github.com/cloudposse/terraform-aws-alb-ingress/blob/main/main.tf#L58-L88 to define our ingress changes.
I don’t recall if we had any changes we didn’t upstream, though. The listener rule is what you want, though @Taimur Gibson.
2024-10-23
2024-10-24
2024-10-28