5 ms·

Maybe someone here can help me figure out what I need, since the world of containers is growing faster than I can understand. I have one code base that I run o

Maybe someone here can help me figure out what I need, since the world of containers is growing faster than I can understand. I have one code base that I run on multiple servers/containers independently of each other. Think Wordpress style. I used to run it on Heroku but I switched to Dokku because it's substantially cheaper and I don't mind taking care of the infrastructure. I like Dokku but I do worry about being tied to just one server and not being able to horizontally scale or easily load balance between multiple servers/regions. Ideally what I'd like is Dokku with horizontal scaling built in. I've seen Deis and Flynn but they seem less active/mature even than Dokku, which is saying something. Is Kubernetes the right answer here or should I stick with Dokku and forget about horizontal scaling?

coreyja 8y ago
I am in the exact same boat as you are, and would love some feedback as well! I have been considering Kubernetes so that I can allow horizontal scaling, but haven't done it yet. For my use case I am VERY well aware that Kubernetes is overkill, but I don't see a great middle ground between Dokku where I am now, and Kubernetes.
- amq 8y ago
  I have found Docker Swarm Mode to be a good middle ground. Essentially, it's docker-compose which you can run on multiple servers.
  - hinkley 8y ago
    I've started experimenting with Swarm myself but I know one guy who has a histamine reaction every time I mention it. I haven't gotten (or really tried to get) a straight answer out of him about why it's a bad thing. If you have a countable number of instances of a couple dozen services and one or two "lots of instances" services it seems like it should suffice just fine. And really, my brief sojourn into Kubernetes left me feeling like I bumped into road blocks for anything more complicated than that. Especially with sidecars, or if your tool chain uses multiprocessing instead of threading (Rails, Node, Python?, etc) to deal with concurrency.
NickBusey 8y ago
The article mentions Stellar (https://github.com/ehazlett/stellar/ https://github.com/ehazlett/stellar/) which may be what you need.
deleted 8y ago
[deleted]
egeozcan 8y ago
IMHO, if you are lucky to have the problem of scaling beyond dokku on a beefy, dedicated server, it's time to hire someone for the devops. YMMV depending on your stack, of course.
Arcsech 8y ago
I haven't used it myself, but https://flynn.io/ https://flynn.io/ seems to be targeted at that use case.
- aemadrid 8y ago
  Last release was in 2017. I don't think flynn is still alive which is a shame.
  - cat199 8y ago
    https://github.com/flynn/flynn/commits/master https://github.com/flynn/flynn/commits/master not at all in the loop here.. but release != alive; alive != new code, etc etc etc
    - KajMagnus 8y ago
      I always check the Contributors graph of an OSS project I'm thinking about using: https://github.com/flynn/flynn/graphs/contributors https://github.com/flynn/flynn/graphs/contributors
turtlebits 8y ago
I found Flynn.io to be a good step up from Dokku - clustered, no containerization knowledge needed.
igneo676 8y ago
If there's nothing wrong with what you have, keep it. There's also theoretically nothing stopping you from setting up a similar server and stand up a load balancer for incoming traffic and use that if you need some redundancy. That's roughly what I do but with docker-compose and a cron job Tooling like Kubernetes might make sense for larger operations but, for me at least, it doesn't seem to make sense and won't make a significant difference in my day to day administration
tetha 8y ago
Kubernetes isn't the only thing around. Kubernetes and Mesos are kinda the heavyweight solutions, but there are smaller things around like Hashicorps Nomad and Swarm, and probably a lot more I don't know. We're currently evaluating nomad, and it's surprisingly pleasant. Nomad doesn't solve every problem every application in every situation might have. Nomad schedules containers, VMs or whatever else on hosts. This reduces complexity a lot. It took us like 1 - 2 man-weeks to have an almost arbitrarily scalable nomad setup which allows you to submit a bunch of jobs and mark some public ports for a loadbalancer, be it mysql, http, whatever. And it's easy to understand and operate. There's 3 nodes of consul, 3 nodes of nomad-server and 2 hosts of nomad-client, some certs in the middle, consul-template + haproxy with a config almost from a blogpost. That's it. It has very few moving parts and it's easy to understand and troubleshoot with 2-3 main guys in our ops team. (EDIT: this doesn't read clear. We have 2-3 guys on our ops team. They are not working on nomad alone. Nomad atm is a low-maintenance system and we're mostly dealing with other crap /EDIT) And now we're just going with it for now. Our CI needs resources for on-demand test-systems, so let's figure out how to make that happen. Our self-service test system for demos / manual acceptance testing needs resources for systems so let's figure that out. We might need to use gluster or something for persistent storage if we want to migrate internal tooling to this. A sister company might want to tinker around with windows VMs scheduled by nomad, or windows containers, so why not? But the good thing: It took us 2 weeks to start delivering business value. That's a relatively small up-front payment for an established company, even a small one. Now we can leave it alone for some time, or we can invest some more well defined packages of time to make it better in concrete, requested ways. That's easy to schedule and prioritize.
- heipei 8y ago
  Just came here to second this. We evaluated both Kubernetes as well as Nomad for a relatively small cluster of some worker nodes and web services. In the end, the ease of standing up a Nomad cluster and the whole feel of the thing won us over. Nomad is a single golang binary that you can run on your laptop and have a fully working working Nomad client and server, along with a builtin UI and command line tools (same binary). The story for production is the same: Throw the binary on your server, setup a systemd unit to run it and you have another Nomad node. If you're evaluating container schedulers and are not sure what you need, take an afternoon or so and just run it locally and play with it. If there aren't any specific features about Kubernetes you could point to that Nomad does not meet my suggestion would be to get started with it first.
katsura 8y ago
Never really tried it, but when I was looking for Dokku and Flinn alternative, I found this: https://captainduckduck.com/ https://captainduckduck.com/
Aeolun 8y ago
Given the limits of applications like flynn, deis and nomad, and having tried all of them, I would be inclined to point you towards just going full kubernetes (in specific, rancher 2.0). It’s a fair amount of effort getting your head wrapped around kubernetes, but the same can be said for the other packages. At least kubernetes seems more likely to be useful in your further career as well.

coreyja 8y ago

I am in the exact same boat as you are, and would love some feedback as well! I have been considering Kubernetes so that I can allow horizontal scaling, but haven't done it yet. For my use case I am VERY well aware that Kubernetes is overkill, but I don't see a great middle ground between Dokku where I am now, and Kubernetes.

amq 8y ago
I have found Docker Swarm Mode to be a good middle ground. Essentially, it's docker-compose which you can run on multiple servers.
- hinkley 8y ago
  I've started experimenting with Swarm myself but I know one guy who has a histamine reaction every time I mention it. I haven't gotten (or really tried to get) a straight answer out of him about why it's a bad thing. If you have a countable number of instances of a couple dozen services and one or two "lots of instances" services it seems like it should suffice just fine. And really, my brief sojourn into Kubernetes left me feeling like I bumped into road blocks for anything more complicated than that. Especially with sidecars, or if your tool chain uses multiprocessing instead of threading (Rails, Node, Python?, etc) to deal with concurrency.

NickBusey 8y ago

The article mentions Stellar (https://github.com/ehazlett/stellar/ https://github.com/ehazlett/stellar/) which may be what you need.

deleted 8y ago

[deleted]

egeozcan 8y ago

IMHO, if you are lucky to have the problem of scaling beyond dokku on a beefy, dedicated server, it's time to hire someone for the devops. YMMV depending on your stack, of course.

Arcsech 8y ago

I haven't used it myself, but https://flynn.io/ https://flynn.io/ seems to be targeted at that use case.

aemadrid 8y ago
Last release was in 2017. I don't think flynn is still alive which is a shame.
- cat199 8y ago
  https://github.com/flynn/flynn/commits/master https://github.com/flynn/flynn/commits/master not at all in the loop here.. but release != alive; alive != new code, etc etc etc
  - KajMagnus 8y ago
    I always check the Contributors graph of an OSS project I'm thinking about using: https://github.com/flynn/flynn/graphs/contributors https://github.com/flynn/flynn/graphs/contributors

turtlebits 8y ago

I found Flynn.io to be a good step up from Dokku - clustered, no containerization knowledge needed.

igneo676 8y ago

If there's nothing wrong with what you have, keep it. There's also theoretically nothing stopping you from setting up a similar server and stand up a load balancer for incoming traffic and use that if you need some redundancy. That's roughly what I do but with docker-compose and a cron job Tooling like Kubernetes might make sense for larger operations but, for me at least, it doesn't seem to make sense and won't make a significant difference in my day to day administration

tetha 8y ago

Kubernetes isn't the only thing around. Kubernetes and Mesos are kinda the heavyweight solutions, but there are smaller things around like Hashicorps Nomad and Swarm, and probably a lot more I don't know. We're currently evaluating nomad, and it's surprisingly pleasant. Nomad doesn't solve every problem every application in every situation might have. Nomad schedules containers, VMs or whatever else on hosts. This reduces complexity a lot. It took us like 1 - 2 man-weeks to have an almost arbitrarily scalable nomad setup which allows you to submit a bunch of jobs and mark some public ports for a loadbalancer, be it mysql, http, whatever. And it's easy to understand and operate. There's 3 nodes of consul, 3 nodes of nomad-server and 2 hosts of nomad-client, some certs in the middle, consul-template + haproxy with a config almost from a blogpost. That's it. It has very few moving parts and it's easy to understand and troubleshoot with 2-3 main guys in our ops team. (EDIT: this doesn't read clear. We have 2-3 guys on our ops team. They are not working on nomad alone. Nomad atm is a low-maintenance system and we're mostly dealing with other crap /EDIT) And now we're just going with it for now. Our CI needs resources for on-demand test-systems, so let's figure out how to make that happen. Our self-service test system for demos / manual acceptance testing needs resources for systems so let's figure that out. We might need to use gluster or something for persistent storage if we want to migrate internal tooling to this. A sister company might want to tinker around with windows VMs scheduled by nomad, or windows containers, so why not? But the good thing: It took us 2 weeks to start delivering business value. That's a relatively small up-front payment for an established company, even a small one. Now we can leave it alone for some time, or we can invest some more well defined packages of time to make it better in concrete, requested ways. That's easy to schedule and prioritize.

heipei 8y ago
Just came here to second this. We evaluated both Kubernetes as well as Nomad for a relatively small cluster of some worker nodes and web services. In the end, the ease of standing up a Nomad cluster and the whole feel of the thing won us over. Nomad is a single golang binary that you can run on your laptop and have a fully working working Nomad client and server, along with a builtin UI and command line tools (same binary). The story for production is the same: Throw the binary on your server, setup a systemd unit to run it and you have another Nomad node. If you're evaluating container schedulers and are not sure what you need, take an afternoon or so and just run it locally and play with it. If there aren't any specific features about Kubernetes you could point to that Nomad does not meet my suggestion would be to get started with it first.

katsura 8y ago

Never really tried it, but when I was looking for Dokku and Flinn alternative, I found this: https://captainduckduck.com/ https://captainduckduck.com/

Aeolun 8y ago

Given the limits of applications like flynn, deis and nomad, and having tried all of them, I would be inclined to point you towards just going full kubernetes (in specific, rancher 2.0). It’s a fair amount of effort getting your head wrapped around kubernetes, but the same can be said for the other packages. At least kubernetes seems more likely to be useful in your further career as well.