It's minor and maybe I'm being petty, but my sympathy for Docker ended the moment they forced you to register an account and log in to download Docker CE.
Why doesn’t anyone weep for Docker?
221–230 of 248 posts
Re: Why doesn’t anyone weep for Docker?
#222Earlier quoted context omitted.
To be honest I only very recently got to know ansible and related techs so I maybe missing an opportunity to learn something. Even so I think you are forgetting the DEV part. With ansible and chef you can make a deployment to the real infra. With containers you can have infra locally in your DEV environment and have clean slates. The similitude of the DEV environment and the production are crucial for devops. There i…
> With containers you can have infra locally in your DEV environment and have clean slates. True, but you can do that with plain system containers such as with lxd, rather than having that bundled with the huge paradigm shift that Docker comes with.
My experience with lxd is very limited. Actually I worked with liblxc which is the underlying paradigm, and i kind of disagree with you. The paradigm of lxd is much more foreign to me than docker. I am pretty familiar with my application and the distro of the container in a user perspective. I am definitely very insecure about cgroups and kernel namespaces. In the end my application is connected with my business/work orders. Kernel minutiae is not and the technical skill requirements is much higher. That will put a higher price tag on my team's human resources.
Re: Why doesn’t anyone weep for Docker?
#223Earlier quoted context omitted.
At last, someone who gets it. Absolutely nailed it. Great answer. I never log into my HN account anymore, but for this response I just had to say: yes. Well said. When you boil the Cloud, DevOps, CloudOps, SecOps, *Ops, CI, CD, Containers, VMs, and all the other technologies we've devised over the past ten years, you always end up at the basic building blocks. You eventually come to the conclusion that all we're real…
Curious about where you see ansible fit in while using Terraform, could you expand on that? Everywhere I have thought I would need ansible to scratch an itch it has turned out that terraform has that functionality in some way (through null_resource, runners).
Terraform is for managing infrastructure. Ansible is for managing configuration. You can argue they're the same thing, but I disagree.
I believe in one tool to do one job really well.
Terraform is excellent at provisioning and managing infrastructure due in part to its DAG and HCL. On the other hand Ansible has been tuned over the years for managing configuration and the state of anything and everything from the OS upwards.
I also believe in using building blocks to get to where you're going, and these two bad boys click together quite well.
Re: Why doesn’t anyone weep for Docker?
#224Earlier quoted context omitted.
At last, someone who gets it. Absolutely nailed it. Great answer. I never log into my HN account anymore, but for this response I just had to say: yes. Well said. When you boil the Cloud, DevOps, CloudOps, SecOps, *Ops, CI, CD, Containers, VMs, and all the other technologies we've devised over the past ten years, you always end up at the basic building blocks. You eventually come to the conclusion that all we're real…
I am a developer, who also dealt with ops in a small business context. I agree with Ansible striking a good balance between prior experience and the future of automating server configuration. I did a write-up on how I used it on my blog: [link redacted] The workflow worked really well, provisioning Vagrant servers in staging and Digital Ocean droplets in production.
Nice write up. Good job, mate.
I moved away from Vagrant in favour of Terraform, but I agree Vagrant still holds its own and is a great choice (HashiCorp really nailed it, eh?)
Re: Why doesn’t anyone weep for Docker?
#225Earlier quoted context omitted.
It was meant to be polite. Under the guise of "clarifying" what I said, you completely contradicted it, without even doing me the courtesy of addressing my statements directly. If it helps, my core point is: DevOps is the name we give to two philosophical ideas. The first idea is that the tools and methods of software development can be used to improve our ability to do operations work. The second idea is that siloin…
I wasn't sure how much your ideas deviated from mine, which I why I said "clarifications"; but you're slightly incorrect. DevOps isn't two philosophical ideas. It's lots of things, and all those things are the methodology. There are many books, podcasts, blogs, conferences, etc that go over all of the things DevOps is. It actually has little to do with tools or software, even though that's basically what it was creat…
Right, it's not a clarification: one of us is objectively wrong.
Re: Why doesn’t anyone weep for Docker?
#226Earlier quoted context omitted.
I'm currently in the process of developing a video training course that teaches Terraform, Ansible, Packer and GitLab (CI) as a set of interwoven, dependent tools. Is this something you feel would scratch your itch? Would you be willing to have a quick chat? I'd pay for your time, of course. I need to gather feed back from people looking to develop their skills into the CloudOps space and understand what it is they'r…
I have been looking for a entry point to start learning containerization and other fancy, related tools that I've been reading on HN in the past couple of years. I mostly write backend code/scripts, so I'm very new to dev ops stuff. The immediate need for me is to package up a C#/.NET web app and its components (DB, etc.) into a container so that I can deploy it on any big-name cloud provider (Azure, AWS, Google Clou…
I think I would start by looking at how-to craft that container by hand. You'll understand the fundamentals better if you do it that way. Once you have a grasp of those, research the tools that then do it for you.
If you deploy a container to a Cloud provider, you'll need to first setup and understand the container engine as well. Not a bad thing to learn, for sure, but again start small and from the bottom upwards.
My tutorials won't cover containerisation because frankly I believe they're overkill for most situations. Sure they're fast and so on, but a slower golden image and a simple EC2 Instance in an AutoScaling Group is easier to understand, manage, and can be just as easily orchestrated.
Re: Why doesn’t anyone weep for Docker?
#227Earlier quoted context omitted.
I wonder how much of that attitude was caused by an overstretched team with no effective scaling mechanism in place. No, "open source" does not automatically mean "scalable team". Part of Kubernetes success is its ability to scale up the community, empowering multiple entities to meaningfully contribute.
At the same time, I gather it's really, really hard to write software that satisfies a lot of use cases across a lot of businesses without having to be somewhat opinionated.
True! Another part of Kubernetes success is the fact that it's core architecture is sound, scalable for both workloads and features.
Re: Why doesn’t anyone weep for Docker?
#228Earlier quoted context omitted.
> With containers you can have infra locally in your DEV environment and have clean slates. True, but you can do that with plain system containers such as with lxd, rather than having that bundled with the huge paradigm shift that Docker comes with.
My experience with lxd is very limited. Actually I worked with liblxc which is the underlying paradigm, and i kind of disagree with you. The paradigm of lxd is much more foreign to me than docker. I am pretty familiar with my application and the distro of the container in a user perspective. I am definitely very insecure about cgroups and kernel namespaces. In the end my application is connected with my business/work…
> The paradigm of lxd is much more foreign to me than docker.
The paradigm of lxd is pretty much exactly the same as the paradigm of a regular distribution installed on bare metal or inside a VM. If you can operate a regularly installed distribution, then you can operate inside a lxd container. The commands to create and destroy lxd containers are trivial ("lxc launch ubuntu:bionic" for example).
> Kernel minutiae is not and the technical skill requirements is much higher.
I'm not sure why you think you need to know kernel minutiae, cgroups or kernel namespaces. Operating lxd needs none of that.
> I am pretty familiar with my application and the distro of the container in a user perspective.
That's all you need.
Re: Why doesn’t anyone weep for Docker?
#229In my experience having worked at two developer tools companies where we wanted to partner and co-market products, Docker would never pick up the phone. There was definitely a “we don’t need you attitude” whenever I approached them and I had the same experience repeated to me by friends at other companies trying to do the same thing.
This is the core reason why they are where they are. They acted like you were bothering them and in fairness you probably were. Even today they wouldn't pick up. When you start believing the hype reality becomes distorted.
The kind of activities we were approaching about were for integrations, conferences, blog posts and webinars - great methods to get leads and remain in the zeitgeist.
Re: Why doesn’t anyone weep for Docker?
#230My experience agrees with this. I'm a huge fan of Docker, I've actively taken part since the early days, attending meetups and using it actively day to day. Unfortunately, when I brought several issues to GitHub, or +1'd other people's issues that were affecting the usability within our company, the attitude was very much "f* you and your problems" because Docker want things to be one way and that's how it'll be. The…
I maintain a couple of docker network plugins. One day Docker devs decided that they would bundle an internal DNS resolver inside the docker daemon and take over the resolv.conf in every container. But here's the most amazing part. It only did this for custom networks. If you just used docker out of the box you would never see this. But if you used custom networks, and custom network drivers, it did this. And the doc…
I ran into a piece of software that was basically impossible to containerize because of this weirdness.
It wanted to ‘mv’ over resolv.conf but couldn’t so we had to run it outside the container because it was proprietary and we couldn’t readily modify it.