switch to podman? https://podman.io/
No docker-compose suppport.
Dissatisfied with Docker
121–130 of 229 posts
Re: Dissatisfied with Docker
#122> In fact, a global system daemon should not be needed. Either users should be able to run their own daemons or container management should avoid having a daemon at all, by storing container state in a shared database. Absolutely love Podman. You can even define registries to work with docker hub, easily. https://podman.io
Yeah but no docker-compose support :/ dealbreaker for us. Theres an alpha podman-compose project but we couldn't get it running.
You really don't need it since podman has pods of containers that communicate with each other. You can export and playback the pods as kubernetes yaml.. but I just use a bash script + an environment file to configure, create and launch pods. What else is docker-compose really doing for you?
Re: Dissatisfied with Docker
#123What's wrong with booting a VM off a standardized base image (e.g. an AMI), and then applying simple deployment scripts for each application you need to run? You could probably replicate 90% of the justification for using docker with some basic scripting. git clone https://github.com/myprofile/my-cool-app cd my-cool-app chmod +x deploy.sh ./deploy.sh That's it. The above script would be responsible for getting your a…
Okay so write your own crappy (excuse me, graceful and elegant) pile of shell scripts that nobody in your company but you understands? Sounds good to me.
The second you leave, somebody is gonna rip that crap out and replace it with docker. All while mumbling under their breath...
Re: Dissatisfied with Docker
#124The article is completely on point. Because of all the reasons exposed there (and a few more) I started Wasmer, a new container system based on WebAssembly - https://wasmer.io/ Here are some advantages of Wasmer vs Docker: * Much faster startup time * Smaller containers * OS independent containers (they can run in Linux, macOS and Windows) * Chipset independent containers (so they can run anywhere: x86_64, Aarch64/AR…
One thing I also find sorely lacking in Docker is the ability to run your containers with the appropriate seccomp privileges (in order to enforce Principle of Least Authority). I know this is possible with Docker, but it's not really done much in practice because of various difficulties. I wonder how difficult it would be to do that with your tool?
You might find the Kubernetes offer interesting. Pod Security Policies[1] expose seccomp and selinux configuration in the form of annotations.
[1]: https://kubernetes.io/docs/concepts/policy/pod-security-poli...
Re: Dissatisfied with Docker
#125Earlier quoted context omitted.
One thing I also find sorely lacking in Docker is the ability to run your containers with the appropriate seccomp privileges (in order to enforce Principle of Least Authority). I know this is possible with Docker, but it's not really done much in practice because of various difficulties. I wonder how difficult it would be to do that with your tool?
Seccomp is a horrible security model for containers, if the application or it's libraries use differing syscalls the seccomp ruleset is invalid
A process making a system call to the kernel functions the same way regardless of whether it is in a container or not. How exactly does the security model differ at all?
Re: Dissatisfied with Docker
#126These are all pretty good points. I can understand why Docker allows any base layer OS, but they could have made their own packages or limited a single distro and it would be easier to check for outdated packages and security issues in containers. The cgroups and Linux specific hooks keep Docker from being implemented natively anywhere else. The fact you have to share the entire Docker socket for containers to be abl…
> The fact you have to share the entire Docker socket for containers to be able to control other containers, or that it's not trivial to run Docker-in-Docker, is terrible.
FWIW, if you enable the remote API, which, granted, isn't as trivial to do securely as it should be[1], then you can connect from any Docker client by simply setting the `DOCKER_HOST` env var and using the right TLS certs. This makes Docker-in-Docker much easier to manage, avoids the security issues of sharing the Unix socket, and works remotely of course.
Re: Dissatisfied with Docker
#127I'm surprised nobody is mentioning LXC[1]. I'm by no means a containers expert, but they claim to be more secure since they default to running as non-root. Unlike docker, I had no trouble installing LXC with apt, while with docker I often got an outdated version. I'm now using LXC for all of my basic container applications (self hosting a wiki and a few other sites). [1]: https://linuxcontainers.org/
Because LXC has no marketing money like Docker. For me it's just one of these cool tools I use every day without giving it a second thought.
Re: Dissatisfied with Docker
#128... then I suppose Selfdock is for you.
* Does not give or require root.
* Fast: Does not write to disk.
* Fast: Does not allocate memory.
* No daemon.
Re: Dissatisfied with Docker
#129What's wrong with booting a VM off a standardized base image (e.g. an AMI), and then applying simple deployment scripts for each application you need to run? You could probably replicate 90% of the justification for using docker with some basic scripting. git clone https://github.com/myprofile/my-cool-app cd my-cool-app chmod +x deploy.sh ./deploy.sh That's it. The above script would be responsible for getting your a…
That approach works, but if you are going to go into production with it you might need to support: - Rollbacks - Automatic deployment of new releases from CI, rolling releases - Healthchecks, detecting if/when the server exits and making sure that VM gets killed - Canary deployments - Autoscaling (could use an autoscaling instance group for it, but what if you need to scale based on other metrics) - Log aggregation -…
None of these features are a function of docker, they are a function of the orchestration layer.
bin-packing isn't what you describe, its shoving as much stuff on a machine as possible. Proper resource dependencies management allows what you describe, something k8s is weak on compared to other orchestration systems.
Re: Dissatisfied with Docker
#130I am currently on this train. Having used rkt in the past, I went to revisit it recently only to find this: https://www.cncf.io/blog/2019/08/16/cncf-archives-the-rkt-pr... I am so extremely disappointed in the CNCF as rkt (at the time, at least) seemed to be more "production ready" than Docker. Are there any real alternatives? Is the answer "find something else that uses containerd in a more friendly way?" Is the ans…
Wasn't that because RedHat bought CoreOS, and RH is all k8s? And then no one was pushing rkt along with commercial support, so it died?
Agree the rkt was cool. I just don't know if RH is becoming more like MSFT or more like Oracle.