3 ms·

If you run a single server, getting a Let's Encrypt cert is as easy as running a cron script. Then you just run a single instance of Nginx with the cert directo

If you run a single server, getting a Let's Encrypt cert is as easy as running a cron script. Then you just run a single instance of Nginx with the cert directory mounted as a volume. You will have to do a little extra work to maintain the nginx configuration to point to all your other containers, but it's generally just copy/pasting a block and changing the port to add a new service. Kubernetes is cool but the only reason to run it on a single instance is because you want to. Also docker-compose isn't used to host stuff in production very often but it is used to manage running local instances quite a bit. I wouldn't write it off as not worth learning.

rektide 6y ago
Comments in this discussion are filled with similar sort of 'it's easy, just do it by hand' sort of advice. Let's Encrypt is an example of one thing that you can either get practically for free in Kubernetes, or which you can keep fiddling & expanding your nginx configuration with, as you add domains & subdomains. Keep hoping your cron jobs are running as they need to. But it's one example. And it's an easy example. If I want a postgres database, it's pretty easy to set up postgres too. I can do it in under 30 minutes. But I should also set up read replicas. I should set up backups. Somehow I have to leave enough documentation so that the next time I need to operator on these systems, or if someone else does, they can follow my work & understand what's happening. I should probably set up monitoring on all these systems, so that if something goes wrong with a replica & lag raises, or if backups don't write, I get notified. I should add metrics so I can see problems as they are developing, increasing my ability to sleep soundly. There's a fractal web of concerns around running & operating software, and the classical path is to become ever more an expert on the niche. To keep diving in, trying to find your own way forward, pick your own stack of tools to help, and document document document test test test everything. Run some chaos engineering tests to make sure these systems you've strung together are going to not lose all the data if something some day does go wrong. Kubernetes should be the default model for anyone who cares about themselves and/or running software effectively. A off-the-shelf postgres operator will let me define a Postgres resource, with as many replicas as I please, and backup schedules as I like. One can install k3s on one node or a dozen nodes, install the helm chart for a postgres-operator, create a manifest for a postgres database, and apply it, in under an hour. Whether you want a tiny small one node postgres, or to run a many replica geo-distributed postgres system, this is a better way to do it, that will yield more predictable results, that more engineers will be able to recognize & identify & work with the pieces of, than what would take me a week of time to set up. Because it flips the model. Rather than bottom-up engineering the pieces of the system, Kubernetes empowers me to define a top-down set of things I desire, and it lets the automation work to fulfill those asks. It take the grunt work out, paves the cowpaths. And Kubernetes does it consistently. After getting a backed up, monitored, replica'ed postgres going in an hour, I can use the same skillset, the same patterns, to deploy Redis. And the next service after that. Even if you are single node, perhaps you might want to use SQS, or S3, or soon Lambdas; maybe as a part of some JAM Stack. Well, with Kubernetes, you can manage that under the same roof too, whether you run Amazon's EKS, or your own Kubernetes at home, or any other Kubernetes. You can manage everything, consistently. https://aws.amazon.com/blogs/containers/aws-controllers-for-kubernetes-ack/ https://aws.amazon.com/blogs/containers/aws-controllers-for-... It's a different operational paradigm, and I think almost all operators would have a better experience, learning & benefiting from a top-down control system like Kubernetes. Using bottom-up engineering to deploy services seems appealing to a large amount of the seasoned engineers of today, it seems easier to them, but they don't get how powerful it is having automation at your back, they don't understand how much clearer operations are when all of your state is centralized & something you can work on with consistent tooling, and they haven't seen how much nicer it is when everything you have can be managed under one roof. They all think it's easy, learning this service, learning that service, that the services are all simple. But lacking this top down system of control, lacking something consolidated & centralized to mange everything, lacking the live-agents/controllers that are tirelessly working to keep things running, it's a huge loss. I hope future engineers can enjoy a much better constructed, much less piecemeal environment.

rektide 6y ago

Comments in this discussion are filled with similar sort of 'it's easy, just do it by hand' sort of advice. Let's Encrypt is an example of one thing that you can either get practically for free in Kubernetes, or which you can keep fiddling & expanding your nginx configuration with, as you add domains & subdomains. Keep hoping your cron jobs are running as they need to. But it's one example. And it's an easy example. If I want a postgres database, it's pretty easy to set up postgres too. I can do it in under 30 minutes. But I should also set up read replicas. I should set up backups. Somehow I have to leave enough documentation so that the next time I need to operator on these systems, or if someone else does, they can follow my work & understand what's happening. I should probably set up monitoring on all these systems, so that if something goes wrong with a replica & lag raises, or if backups don't write, I get notified. I should add metrics so I can see problems as they are developing, increasing my ability to sleep soundly. There's a fractal web of concerns around running & operating software, and the classical path is to become ever more an expert on the niche. To keep diving in, trying to find your own way forward, pick your own stack of tools to help, and document document document test test test everything. Run some chaos engineering tests to make sure these systems you've strung together are going to not lose all the data if something some day does go wrong. Kubernetes should be the default model for anyone who cares about themselves and/or running software effectively. A off-the-shelf postgres operator will let me define a Postgres resource, with as many replicas as I please, and backup schedules as I like. One can install k3s on one node or a dozen nodes, install the helm chart for a postgres-operator, create a manifest for a postgres database, and apply it, in under an hour. Whether you want a tiny small one node postgres, or to run a many replica geo-distributed postgres system, this is a better way to do it, that will yield more predictable results, that more engineers will be able to recognize & identify & work with the pieces of, than what would take me a week of time to set up. Because it flips the model. Rather than bottom-up engineering the pieces of the system, Kubernetes empowers me to define a top-down set of things I desire, and it lets the automation work to fulfill those asks. It take the grunt work out, paves the cowpaths. And Kubernetes does it consistently. After getting a backed up, monitored, replica'ed postgres going in an hour, I can use the same skillset, the same patterns, to deploy Redis. And the next service after that. Even if you are single node, perhaps you might want to use SQS, or S3, or soon Lambdas; maybe as a part of some JAM Stack. Well, with Kubernetes, you can manage that under the same roof too, whether you run Amazon's EKS, or your own Kubernetes at home, or any other Kubernetes. You can manage everything, consistently. https://aws.amazon.com/blogs/containers/aws-controllers-for-kubernetes-ack/ https://aws.amazon.com/blogs/containers/aws-controllers-for-... It's a different operational paradigm, and I think almost all operators would have a better experience, learning & benefiting from a top-down control system like Kubernetes. Using bottom-up engineering to deploy services seems appealing to a large amount of the seasoned engineers of today, it seems easier to them, but they don't get how powerful it is having automation at your back, they don't understand how much clearer operations are when all of your state is centralized & something you can work on with consistent tooling, and they haven't seen how much nicer it is when everything you have can be managed under one roof. They all think it's easy, learning this service, learning that service, that the services are all simple. But lacking this top down system of control, lacking something consolidated & centralized to mange everything, lacking the live-agents/controllers that are tirelessly working to keep things running, it's a huge loss. I hope future engineers can enjoy a much better constructed, much less piecemeal environment.