Anyone here experience with docker?
Tried it out on windows, and as usually with dev tools on Windows that rely too much on GNU tools or the linux kernal it completely died on me.
I'm currently planning to rent a VPS and run some (web)applications on it.
The VPS supports CoreOS, so docker is an option. Probably going to run two Golang containers and a PostgreSQL server in another container.
Is it worth it though? It seems like such a hassle. I have to write Dockerfiles and do --link magic (which I don't understand, how do I connect the Golang app in one container with the SQL server in the other?)
Maybe I should just throw all applications just on the main OS?
Any suggestions or personal opinions on Docker here?
I like docker for other things than containing applications. I use it for portable dev conditions anywhere. It's good for that. I would personally recommend just putting the applications on one server, or even better having a separate server for your DB.
Docker doesn't get mentioned much here by itself, usually only in context of actual programming stuff
>>52031690
I've worked with docker at my job. Java dev, our project was a java app server + sql db + website.
Docker is for quickly deploying multiple instances of programs, hosted inside a lightlweight linux OS customized for just that program, like an instance of your http server or an instance of your processing backend.
--link enables some exchange of environment variables between containers. If you --link your java app server containers to your sql container, the java app server will be able to access environment variables created and shared by your sql container, like connection strings (so you configure your sql access in your sql container and your java server will just read the data from it instead of having to include those connection strings in your app server directly) or whatever else is relevant. It's up to dockerized programs to decide what they share when linked. See it as selective namespace sharing or something. It's just for passing variables between containers so that they're dynamically configurable.
Docker files are like build scripts for the linux OS in your container: they describe which distro to base it on, programs to install, settings to modify, files to copy in, scripts to run during compilation, etc. They're like a blueprint for your container (you don't share compiled container files with each other, just the dockerfile, they always compile to the same final container OS)
It's brety gud but only if you actually need it.
>development on windows
In all seriousness, avoid using meme technologies on Windows. You'll run into all sorts of problems and edge cases.
Docker has a small learning curve, but it is useful. Making Dockerfiles is easy.
>>52032358
>>development on windows
>the OS I work in influences the quality of my work and my ability to perform it
It works 2 ways pal, and it comes down to just not being familiar with the differences between them.
>>52032385
Yes, the OS I work in does influence the quality and ease of my work. What's your point? I use Windows for regular usage, and *nix for all development and deployment.
>>52032432
I just get triggered by /g/ memers spouting that stupid "you can't do dev on windows" meme
>>52032494
I don't mind Windows, but so much open source shit is designed for Linux first, and Windows second or third, if at all. It's just not worth the headache. And while Powershell is nice, bash/zsh/fish is more terse and better for ordinary use.
I don't understand why anyone would do dev work on Windows, except for .NET and Windows GUU stuff.
I get the appeal of docker but it just seems like a trade off pushing the hassle from you the developer unto the end users. It's like shipping a FreeBSD Jail or Solaris Zone to someone else, it will work fine every time so long as they actually have the OS underneath it to support it, so now they have to run an entire OS just for one application. Seems a little silly to me, it's like targeting the JVM except much bigger and less portable. Maybe I'm misunderstanding it.
>>52032554
Things like that make me wish people targeted POSIX more often than relying on GNU and its extensions.
If you are asking about why its useful, it isn't useful to you. Docker is a meme
>>52032586
Docker is not for running plain apps. It's for use on servers.
>>52032638
What I'm saying is I don't see the need for these things to be so unmanageable on their own that they require an OS instance just for an application, things should be designed in a way that you can set them up on any OS without problem, operating systems have their own methods for isolation as well like the aforementioned Jails, Zones, and even chroot, even Windows lets you segregate third party tools so they don't conflict with each other.
I just don't understand why people take all these existing technologies like sql databases, web servers, etc. and combine them in a way that is so specific instead of a more general and interoperable way. Targeting specific versions and making assumptions on the state of these things seems like bad design, I understand it if you absolutely need rapid development but other than that I don't think the overhead cost for each instance is worth it.
Serious question. Why use Docker when you can just use a VM?
>>52032710
That's just one extreme end of the spectrum and the one where docker indeed makes no sense.
In our project it was plenty useful because docker PROVIDED that interoperability.Our containers were pumped full of scripts they wrote until eventually the entire thing managed itself. We could just deploy more instances of some containers and everything worked itself out, using the --link features to auto-configure everything and whatnot. Stuff like config files for programs was all generated on the fly too during deployment. The classic way would require either a single, inflexible config file for every instance (which of course isn't always possible) or someone to manually tweak each instance after compilation in order to make it actually runnable. With docker that was all automated: files were injected and modified during build, dependencies checked and downloaded on the fly, etc.
>>52032733
I'm getting tired of explaining the same fucking thing over and over.
Go read the faq or some shit.
Also, simple answer: if you need 20 instances of your VM, you're gonna have to run 20 VMs. Docker runs as a single VM within which your containers are just processes with shared resources, not full VMs with redundant, duplicate, isolated resources. Enjoy your performance if you use VMs in that situation.
>>52032766
Interesting, thanks for the insight.
>>52032733
VM's (even hypervisors) have a bigger resource overhead usually than just isolating things. Creating and spinning up something like a jail can take a small second while having near no overhead.
>>52032781
Not the guy that asked, but thanks for the answer.
An analogy would be 20+ year old mainframes (IBM iSeries, AS400, VMS Alpha) that "partition" the OS pretty much how you have described.
It's funny how we've come full circle :D kek.
Is Docker still insecure? I heard of instances when applications actually managed to get out of docker/the kernel namespace.
>>52031690
>I have to write Dockerfiles and do --link magic
docker-compose can put this into a single config file
yeah it's a bitch to develop for and to debug, I used it and use it for a small project
too bad the really cheap VPS can't run Docker images
I use Docker with Armada for microservices support at work, and desu it's quite cool. Docker itself makes deployment/development easier by packing all dependencies into a single `isolated` container.
Also, joining/sharing a docker based project is way easier because everything has to be configured inside the container, so all the bullshit like missing libs, version conflicts and stuff, differently configured systems goes out the window.
>>52033430
i heard it was fixed but in the way of adding better ACL, i think it was all a matter of just not having security vs being exploited.
>>52033567
We're about to deploy a huge SaaS platform next year built on docker in golang. The key thing though was server provisioning since machine doesn't take care of a lot of the important things like operator or developer logins for monitoring/debug, theres also the issue of volumes being completely outside the scope of docker, so we're using ansible as well. The whole thing together is quite impressive, single command brings up 5 machines, 3 to run docker in a swarm cluster with replication out the ass, the other two are traditional servers running databases and management type stuff.
One thing that's still up in the air is how to do authentication, really close to using Vault but not sure if it's worth the logistics(currently users are just stored in the application db server).
just noticed that the docker-logo is a setup which would kill the whale dead.
Docker Docker Docker Docker Docker Docker Docker Docker Docker
Mushroom! Mushroom!
