4 ms·
Yes, this is one of those things that was easier before kubernetes. Before: Your developers have a shared Linux box that serves the preview environment. Your r
by phendrenad2 4y ago
Yes, this is one of those things that was easier before kubernetes.
Before: Your developers have a shared Linux box that serves the preview environment. Your ruby app has a tiny loader in front of it that loads the app code from a specific directory based on subdomain.
After: You need to route subdomains to different kubernetes containers, and handle deploying new containers when the developer opens a PR (because it's much more work than just copying files onto a server), and you need to handle destroying old containers (because it's much more work than just deleting files on a server).
Not to mention, usually kubernetes is managed by "the ops" who don't know anything about the app. Much more difficult to interface with them when it's not "oh one server, and the developers figure it out, and if they royally fuck it up we'll rescue them".
- shamiln 4y agoIt’s really not that difficult to automate it over helm or something. All you need is a registry, and most cloud services provide a registry, even GitHub has one. Routing domains to a container shouldn’t be significantly different to doing it in production.
- tracker1 4y agoFor that matter, you generally will have a single app firewall or ingress server that reverse-proxies to your application anyway.
- phendrenad2 4y agoHelm, registry, firewall, ingress, reverse proxy, these are all concepts that whoever sets up this hypothetical staging environment will have to know about, and will also have to be a developer (in order to care). So basically you need a senior dev to either love kubernetes or learn enough of it to get the job done. This is what I mean by "harder".