ctop

ome sort of an orchestrator I'd say that going from Docker Compose to Docker Swarm is the first logical step, because it's included in a Docker install and also uses the same Compose format (with more parameters, such as deployment constraints, like which node hostname or tag you want a certain container to be scheduled on): https://docs.docker.com/compose/compose-file/compose-file-v3... That said, you won't see lots of Docker Swarm professionally anymore - it's just the way the job market is, despite it being completely sufficient for many smaller projects out there, I'm running it in prod successfully so far and it's great. Another reasonably lightweight alternative would be Hashicorp Nomad, because it's free, simple to deploy and their HCL format isn't too bad either, as long as you keep things simple, in addition to them supporting more than just container workloads: https://www.hashicorp.com/products/nomad That said, if you don't buy into HashiStack too much, then there won't be too much benefit from learning HCL and translating the contents of various example docker-compose.yml files that you see in a variety of repos out there, although their other tools are nice - for example, Consul (a service mesh). This is a nice but also a bit niche option. Lastly, there is Kubernetes. It's complicated, even more so when you get into solutions like Istio, typically eats up lots of resources, can be difficult to manage and debug, but does pretty much anything that you might need, as long as you have either enough people to administer it, or a wallet that's thick enough for you to pay one of the cloud vendors to do it for you. Personally, I'd look into the lightweight clusters at first, like k0s, MicroK8s, or perhaps the K3s project in particular: https://k3s.io/ I'd also suggest that if you get this far, don't be afraid to look into options for dashboards and web based UIs to make exploring things easier: - for Docker Swarm and Kubernetes there is Portainer: https://www.portainer.io/ - for Kubernetes in particular there is Rancher: https://www.rancher.com/ (they are also the people behind K3s) - Kubernetes also has its own dashboard, but it's a bit less nice in my opinion: https://kubernetes.io/docs/tasks/access-application-cluster/web-ui-dashboard/ - Hashicorp Nomad comes with its own web UI as well, though I recall it being a bit barebones: https://developer.hashicorp.com/nomad/tutorials/web-ui In the terminal, there are also a few useful projects: - for Docker, there is ctop: https://github.com/bcicen/ctop - for Kubernetes, there is k9s: https://k9scli.io/ As for a desktop UI, there are a few options too: - Docker Desktop: https://www.docker.com/products/docker-desktop/ - Rancher Desktop: https://rancherdesktop.io/ - Podman Desktop: https://podman-desktop.io/ You don't strictly need any fancy tools like that and Docker/Podman CLI, or kubectl can be enough, but sometimes a more visual look and being able to click around can be nice.

iewing the logs or even connecting to containers through a web UI if need be. The webhook functionality in particular is really nice - you can just do a curl request against a given URL and that will pull the new container versions for the given image and do a redeploy, which works nicely with a variety of CI solutions. When I last tried, initializing Nomad clusters with networking encryption was a bit less of a smooth experience (needing to essentially manage your own PKI) and the web UI felt more like a dashboard, instead of something that you could click around in, if you're a proponent of that workflow. Rancher is probably better than both of those options, though there's a certain overhead in regards to running both that software and a full Kubernetes cluster. If Kubernetes feels like a good fit for a particular project and resources aren't an issue, definitely check it out! You can, of course, also have some success with lightweight clusters, like K3s: https://k3s.io/ I'll definitely agree that Lazydocker is a nice tool, but I wouldn't call it superior, just different (TUI vs GUI), their demo video is nice though: https://youtu.be/NICqQPxwJWw It actually reminds me of ctop, which you might also want to check out, though it's not something that you'd manage clusters in, merely the individual containers on a node (which won't always be enough, same as Docker Compose isn't): https://github.com/bcicen/ctop Regardless, for Kubernetes, I'm inclined to say that you'd enjoy k9s a bunch then, it has a similar TUI approach: https://k9scli.io/

age individual code chunks/blocks and spread out/group changes that have already been done in files over multiple commits feels like a nice quality of life improvement. Plus, the diffs that something like the JetBrains IDEs show you, as well as the ability to look at the history for a particular selection is also nice. Then again, there are also many who don't rebase their branches, or even don't select squashing merge commits in whatever UI they might use (e.g. using GitLab/GitHub for their code review functionality and other features), which some might dislike for any number of reasons. I guess that just shows that there are many different workflows and people flock to whatever they feel comfortable with (or whatever their org/team mandates). As for the actual CLI, in general there are few programs out there that actually feel good and usable to me, one of which is the Docker CLI (for the most part). I actually compared its discoverability/usability to something like tar previously here: https://news.ycombinator.com/item?id=29339018 Something like Typer actually let's you create your own interfaces like that, though the new formatting is a bit curious: https://typer.tiangolo.com/ That said, I wish we had more TUI software as well, such as https://k9scli.io/ or even https://github.com/bcicen/ctop Edit: actually one bit of functionality from Git that I miss would be telling it to treat certain changes in the working copy as something that shouldn't show up as modified, but also not even show up as something that can be staged/committed. Maybe something like stash, but whilst keeping the modified files in the working copy. For example, a local database instance that I have doesn't work with how the app wants to use it (suppose that I cannot fix this for any number of reasons) and therefore I need to change every instance of: ORDER BY NLSSORT(some_column, 'NLS_SORT = custom_nls_value') to: ORDER BY NLSSORT(some_column, 'NLS_SORT = standard_nls_value') across the codebase, which means that I might have 100+ changed local files. I just need those changes locally so the local database would launch and keep working, but I don't want to have to look at all of these files as "changed" when deciding what to commit. Of course, at that point you might run into some hot water regarding what would happen if the files that contain this value would actually be altered.