|
revmoo posted:I need a new server node spun up. I provision the VM and deploy a docker image to it. Then I deploy our app to the node. The typical/intended use case for Docker is that you package the application within the image. Deploying your app would mean building and pushing a new image and then docker runing it on the node. At places I've worked where we use Docker, the Docker image is the deployable artifact that a build produces. revmoo posted:Yeah, like our whole stack minus application code and db contents etc. A big part of Docker's value is that it allows you to tease those dependencies apart, or at least separate them from your app. Your app should be running isolated in its own container and you should be telling it where its dependencies are at runtime (usually with env vars but you can also do things like "link" containers that are colocated on the same node). acksplode fucked around with this message at 22:16 on Sep 28, 2016 |
#
¿
Sep 28, 2016 22:13
|
|
|
|
| # ¿ May 7, 2024 07:27 |
|
|
Plorkyeran posted:Hashicorp is just the latest company to discover that the red hat model has not worked for a single company other than red hat. If you're using a large open source project that's being developed as the primary focus of a company then you should probably assume that it will eventually become not open source. The alternative to selling support for your open source project is selling a hosted service, so my takeaway is that Terraform Cloud must not be doing so hot in the market. Trapick posted:I think this depends on whether they had all contributors sign a CLA, and what exactly that CLA contained. Yeah one of the common reasons a project would adopt a CLA is to retain rights that would allow it to relicense code without needing permission from contributors. I'd presume Hashicorp has their bases covered there.
|
|
#
¿
Aug 17, 2023 18:16
|
|
|
Some assorted thoughts: * Readiness probes are intended for letting loadbalancers know which pods can serve traffic, so using them with a service that doesn't receive traffic is a smell. * Exposing application liveness to the kubelet is sufficient reason to add a simple webserver with a /healthz endpoint IMO. All it has to do is serve 200s. But liveness probes are for identifying running pods that can't do work and need a restart. Since your application is politely dying on its own when it can't do work, a liveness probe wouldn't buy you much. * Helm isn't really intended for determining application health, so trying to make it responsible for that is a smell. It's a convenience that a helm release may fail due to liveness or readiness probes, but IMO that's not reason enough to use them where they don't otherwise make sense. I'm actually not sure what conditions will cause helm to report a release as failed except for failing to render and apply manifests, since that's all I really trust it to do. Basically from my perspective your application is behaving reasonably, but CI and observability are lacking. A couple leading questions: * Why did it take 15 minutes to alert on a deployment that obviously bad? Pods in crashloopbackoff would be a fine condition to alert on, in addition to whatever metrics you've implemented in the service. It seems like a problem if "poo poo completely don't work" takes 15 minutes to surface to a human. * Why is CI relying on helm to know whether the application is healthy? A good thing to do would be to directly assert that all pods are running. A better thing to do would be to drop a job into the queue and assert its result arrived at the expected destination.
|
|
#
¿
Sep 7, 2023 01:39
|
|