They tried that on my 15 years old account, then they reverted it back because I could still watch them in incognito windows, or stopped completely watching Youtube.
I am not very profitable to them anyway, but they appear to test you for a couple of days and see how you would react.
Unironically this. After trying Kubernetes, Terraform, Ansible, and various proprietary PaaS config formats, I've grown to love Compose files' simplicity.
I'll happily try anything simpler than that if you give me an idea what that might be.
Not trying to be salty or anything – I really think Compose hits the sweet spot of abstraction which is less complex than both the monstrosities I listed and the ad hoc Bash scripts copying code over SSH and restarting services approach (so, the other extremity of declarative v. imperative).
Actually yeah! A single node is usually enough for me though, but I like the ability to throw in more nodes as needed (more or less painlessly, as long as you properly guard services that need persistent volumes with a label constraint).
Shameless plug: I also make a Docker Swarm dashboard, check it out: https://lunni.dev/
What strikes you as difficult with compose files? In fact, I would say it’s the most concise format to describe a desired state of running applications currently available.
Compose is an open source project entirely separate to hub, though. The compose file specification is versioned separately, and will outlive Docker, probably. So I don’t quite get your criticism?
How are you using compose without docker? They are joined at the hip, criticism of one is criticism of the other.
The days of cheap money are over, it's inevitable that certain SaaS companies will start tightening the screws on their users to match the returns they can get with cash in a bank. I just wish lxc (which docker was built off) got a chance to gain traction. It's miles ahead in DX and sure they serve different functionalities but can be used the same and the network effects can't be understated.
No, that isn't true. Compose can absolutely be used with Docker replacements, and there is no reason you couldn't create an implementation for LXC, for example.
> Compose can absolutely be used with Docker replacements
Can you point to some examples of this?
LXC has profiles which can be mixed and matched for containers, it's got far more extensibility, compose files are a one-shot creation that gets copy/pasted/modified all over the place (we're all guilty of this), you need to read every single compose file and reboot unlike additively popping another profile on a linux container while it's running.
I'd really disagree that compose files are somehow one-shot, or blindly modified. To the contrary, really, we have them checked in with the source code. Upon deployment to the cluster, the (running) services will be intelligently updated or replaced (in a rolling manner, causing zero downtime). LXC might be more elegant, but I have no idea what simple, file-based format I could use to let engineers describe the environment their app should run in without compose.
I need something that even junior devs can start up with a single command, that can be placed in the VCS along with the code, and that will not require deep Linux knowledge to get running. Open for suggestions here, really.
Wendover production is a good quality channel that I always recommend. That being said, their explinations of the problems at hand are always too simplified and limited. Yes the topic is much more complex, but by the end of the video you will end up with some idea about the topic. It is a way to fill some curiosity and satisfy clicks. It can not be taken as any source of knowledge or 101 introduction into topics.
