DevOps

1652 readers

1 users here now

DevOps integrates and automates the work of software development (Dev) and IT operations (Ops) as a means for improving and shortening the systems development life cycle.

Rules:

Posts must be relevant to DevOps
No NSFW content
No hate speech, bigotry, etc
Try to keep discussions on topic
No spam of tools/companies/advertisements
It’s OK to post your own stuff part of the time, but the primary use of the community should not be promotional content.

Icon base by Lorc under CC BY 3.0 with modifications to add a gradient

founded 1 year ago

MODERATORS

[email protected]

EKS Dev environment? (lemmy.world)

submitted 5 months ago by [email protected] to c/[email protected]

8 comments fedilink hide all child comments

Hi all! Not sure if this is the right place to ask this but here goes:

Currently working on a migration from ECS to EKS. I have one working environment that includes one namespace running some containerized services and an EC2 instance running some other services required for the environment to function.

Dev envs look like this today: One EC2 instance running all services, some through Docker and others through PM2.

My question is: Does it make sense to replicate this format for every developer? A namespace running services and an EC2 instance running some others? Or keep it as it is today and replace pm2 for local k8 orchestration?

Thanks in advance~

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 0 points 5 months ago (1 children)

Yes, I guess the rollout will be dev -> Preproduction (environment that equivalent to production) -> Production
No downtime, but why would that be an issue? I make a deployment, old pod goes down, new pod goes up.
That is mostly my job. My manager suggested I calculate the cost of moving the containerized services outside the instance and have them run on the cluster in a separate namespace (meaning 1 namespace for every developer).

No gods, no masters!

[–] [email protected] 0 points 5 months ago (1 children)

As long as you have something besides prod you’re probably fine for now. If you need dev to be more “real” later you can add it. It’s a two way door: https://shit.management/one-way-and-two-way-door-decisions/
Interactions between k8s pods during a deploy, and PVs moving between nodes mainly. K8s just has a metric butt ton of moving parts and as you deploy more stuff to it over time you increase that number of moving parts
yeah, one namespace per dev could be fine. Are you using helm? Kustomize?

[–] [email protected] 0 points 5 months ago (1 children)

Yes, I guess you're right. shit.management is a good domain name.
I guess I'll find out when I get there, still at a beginning of a deployment pipeline
I am using deployment manifests. Not too sure what Kustomize is, I'm still quite a noob

[–] [email protected] 0 points 5 months ago (1 children)

Just writing deployments by hand? That’s probably not going to be super fun to manage across a couple clusters and a bunch of namespaces. Might be worth looking at kustomize a bit before you get to having a real prod environment. I use helm at work but it seems like people consider kustomize to be the new hotness.

[–] [email protected] 0 points 5 months ago

I wrote an automated tool to migrate all my ECS tasks to deployment files (seperated by Deployment, Service, SA and Ingress) just to get a running start. I'll have a look at Kustomize, thanks for the heads up!