Another advantage to application containers is integrations with things like VSCode. Your whole dev environment for a project can live in the container. It makes entry to helping with projects much easier. For example you can include a Dockerfile in your project and VSCode will build the container according to your Dockerfile. Then you can have VSCode spin up the container and attach to it and you can do the development inside of the container. That way the contributors don't need to install anything on their systems to work with your project. It's a really nice work flow.

@Dashrender said in MailCow in Production Datacenter: Question for Scott - the customer wanted self hosted email? why? It's a commercial mail hosting business. Among other things.

@scottalanmiller these discussions echo my thoughts exactly. I'm only (hesitantly) learning Docker now, but it feels like it's not a long term answer(I'm possibly too late to the party?), as other approaches are increasing in mind-share.

@JaredBusch said in Conatainers (Docker) vs VMs - When and Why?: @Obsolesce said in Conatainers (Docker) vs VMs - When and Why?: Are there many use cases in the SMB outside of Dev? Not even in dev really for the SMB. Just use a single VM to do the work. SMB rarely needs to scale. Other than as you stated, the solution is presented that way. Like UNMS. Even enterprise rarely need to scale that way. It's more for hosting companies than anything.

Another thing to note. I believe it's the rabbitmq password that can't accept an @ in the password.

@scottalanmiller sorry I wanted to answer @flaxking but ended up replying to yours reply xD

@devops1 said in Kubernetes (Kubespray) Issue.: @stacksofplates Thank you very much It works. No problem!

@flaxking said in Check my 2 min audio theory on Containers: @scottalanmiller said in Check my 2 min audio theory on Containers: @flaxking said in Check my 2 min audio theory on Containers: What you're talking about is one aspect of part of implementing DevOps that is often misinterpreted to mean the whole of it. And yes, it is stupid to call that DevOps. That's just Ops using different tools. I see it as the opposite. Patrick's core DevOps... "Thanks to the devopsdays conference, the idea of devops seems to live on. While talking with other people about it, I realize that it is difficult to frame it within the current IT landscape. At lot of the ideas are coming from different kinds of emerging technologies (T) and process management (P) approaches. For me the two most important observations are: there is a increase in feedback loops between business, all parts of the delivery process and operations thanks to this feedback loops we increase the quality and speed up the flow" This is the core of DevOps, not well described, but pretty clearly about IT, not development. This is the core. Very, very loosely defined to the point of useless, sure. Then things like DevOps talking dev itself is the extra, the tack on later. It's not "part of" devops, any more than it is of any operations. And just how operations doesn't cease to exist without developers, neither does DevOps. I believe everything on that page is all meant to be within the context of companies doing development. But I agree, the core of DevOps is about Ops and Business practices. However, I firmly believe the name DevOps comes from Ops and Development working together, and thus the reason why discussions of DevOps implementation specifics centre around companies doing software development. Though just based on that page, I could see why someone could still take a different view. However, I consider The DevOps Handbook to be the definitive source, rather than notes on the initial discussions. I think doing that makes DevOps a pointless, useless concept. Hopefully that's not what he intended. As an ops practice, it has tremendous value. As a merger of dev and ops, it's just bluster.

@vhinzsanchez Containers are lighter and faster. And they are a type of virtual machine, Type-C virtualization. So things like performance and density alone are reasons that containers are popular.

Please mention another reason for not using Docker with Linux based operating systems: If the UID on your host system doesn’t match the UID of the user inside your Docker container, you will have file ownership issues. I think most people don’t encounter this because they are probably the only user on their development machine, and most people only add a single user in their Dockerfile to run their app. I’m not sure about other Linuxes, but Ubuntu will assign the first user a UID of 1000 so if you’re the first user on an Ubuntu host and you have an Ubuntu-based Docker image, you won’t even notice. Personally, i was given advice to avoid host volumes even though the case can be resolved with bindfs and a privileged machine in a Windows environment.

@triple9 said in Introducing FreeNAS Corral: @travisdh1 said in Introducing FreeNAS Corral: @mlnews Are they going to add in a kitchen sink for the next release? Somehow I don't see this becoming the next @scale. not yet, for sure https://www.theregister.co.uk/2017/04/18/freenas_downgrades_latest_release_to_tech_preview/ Whoops

@AlyRagab The web UI benefit is that it allowed me to understand why everytime I launch container it spawned a new one and made new generic name for it, and helped me understand more visually. However You can do much more from it, than stop/start/restart/commit containers, and monitoring them. When it comes to doing edits its advised you do everything from command. I actually never heard of supervisord until you mentioned it, thus I ran the default which I reckon is each process in a separate container and never had any issues yet. For me the important thing I learned exploring docker is distinction between application containers and OS containers, and how to approach each. Since you mentioned centos in docker, you might want to check Alpine Linux images, cause they fit the Just enough OS ideology of docker (or was that VMware Photon).

@Romo I should find out soon enough. Just finished spinning up a new VM for this.

@JaredBusch there is another project that took the PocketMine code and tried to run with it that I am looking at. Haven't had much time to dig into it today yet, though.

One thing to add, I'm not sure with docker but with LXC you can set resource limitations with cgroups.

@travisdh1 said in ResinOS Brings Docker to ARM: @scottalanmiller said in ResinOS Brings Docker to ARM: @travisdh1 said in ResinOS Brings Docker to ARM: Hopefully for use in something a little more powerful than a Pi. As much as I like Raspberri Pis, they just don't have the power. Scotty! More power! Lots of powerful ARM devices out there these days. Nvidia's shield? Bet that would run some containers with ease. It would, for sure. I have the top end Shield and that baby has some serious power. Several cores, integrated GPU, 3GB RAM.

Nice deal!