Do you know the acronym ABM?
If you're not a native German speaker, probably not.
Arbeitsbeschäftigungsmaßnahme.
Docker, k8s ... it's all there to employ the unemployed. Also to make something simple complicated so Cloud providers can monetize even this part and lock you in and bill you 10fold for something that really isn't that expensive
VSCode, Dev Containers and Docker
141–150 of 234 posts
Re: VSCode, Dev Containers and Docker
#142Earlier quoted context omitted.
Consistency between team members. Super easy for new team members to get started on a project. No need to manually install dependencies. Environment versioning in git and docker. Your local environment gets automatically updated with a git pull.
> Super easy for new team members to get started on a project. No need to manually install dependencies. I see this brought up a lot as an argument. So why do we want this? How often do people switch companies? Once every 3 years on average or something? Getting your development env setup takes what, a few hours max on 3 years?
> So why do we want this?
Just yesterday, I ran into an issue where a set of node unit tests were failing. My college and I were both getting failures, but different failures. The reason was: Different versions of Chrome, and thus different versions of the chrome integration plugin.
Given that we have effectively no control over Chrome's auto-updates, we'll never have truly identical development environments. A container with headless chrome would have resolved this for us.
Re: VSCode, Dev Containers and Docker
#143Slightly off-topic, it really irks me when people take about reproducible builds/environments while using docker, while having something along the lines of apt-get update/pip install in their dockerfile. Like that completely destroys the reproducibility of your container!
Depends on how you do it, right? For instance, we create base images configured with SDKs, libraries, frameworks, configurations, binaries, etc... Those base images are then built, versioned, tagged and then pushed to our container repos ready to be used by developers, CI/CD, etc... Images based on these base images never need an apt-get, pip install, etc... If there is a dependency missing, updated needed, etc... we…
That solves the problem one way, but I don't know if I would call it reproducible. You're working around the fact that it's not reproducible by only doing it once. You don't get the benefits, e.g. everyone who uses your images has to trust that you built them the right way.
Re: VSCode, Dev Containers and Docker
#144Earlier quoted context omitted.
Anti-pattern 1 perfectly describes how I am (hamfistedly) using Docker. Thanks! However, it doesn't really explain how to fix my mindset. It just says that I should ;-) Could you give me some hints?
"There is no easy fix for this anti-pattern other than reading about the nature of containers, their building blocks, and their history (going all the way back to the venerable chroot)." Basically learn the basics (cgroups, namespaces) You should also study this https://github.com/p8952/bocker
> Basically learn the basics (cgroups, namespaces)
I think I have a basic grasp of those things, but still don't get how Docker uses them.
> You should also study this https://github.com/p8952/bocker
Cool! That's very usefl!
Re: VSCode, Dev Containers and Docker
#145As amazing and convenient as Docker is in practice, containers hide the inherent mess that is modern computing, and the more they are used, the less chance is that this mess is getting cleaned up... ever. Ultimately this is another dependency, complexity hidden by another layer...
> containers hide the inherent mess that is modern computing, and the more they are used, the less chance is that this mess is getting cleaned up... ever
If you have a roadmap for how 150 or fewer engineers can "Clean up the inherent mess that is modern computing" in less than 5 years, then I'd be eager to read it. In the meantime, tools which enable people to manage the symptoms of that mess are good.
The Chunnel lets us work around the fact that the ocean has not yet been boiled away.
Re: VSCode, Dev Containers and Docker
#146Earlier quoted context omitted.
All of those benefits were solved problems with VM based workflows using something like Vagrant long before Containers started gaining traction (IMO). Don't get me wrong, I am a fan of containers (in particular LXC), but I wouldn't list those benefits as if they are unique or novel to container based workflows. Edit: To be clear, there _are_ benefits to containers over VMs, just not the things you listed above from m…
Overhead... it's all overhead. Starting and connecting to a VM isn't nearly as streamlined as connecting to a Docker container (even if it is also running in a VM). Even the hurdle of SSH'ing to a VM is more cumbersome than `docker run`. Certainly this could be automated and scripted, but the Docker solution is so... streamlined. And I say this as someone that used to use Vagrant. With smaller installs available (suc…
I can't name a more dysfunctional hypervisor than VBox. If my choices were a Virtual Box VM or superhacky Docker-as-VM, I'd pick Docker every day.
But I'd say VMs and containers solve different problems. In the case of dev environments, VMs are too "persistent" and accumulate personal cruft very quickly. Container tooling can be built to be noninteractive.
Re: VSCode, Dev Containers and Docker
#147Earlier quoted context omitted.
I'm interested to know your alternate solution. How would you recommend getting the required libraries into your image?
I guess the OP meant such that apt/yum/dnf/whatever runs every time the image runs, rather than just once when it's built. Not that that's something I see very often, mind.
Isn’t the standard approach here then to derive from base images, which have exact versions? Being honest, I’m not a Docker/VM legend but I’ve seen a few attempts at managing this, and base images was one of them.
Personally, I don’t see the issue with it if you’re at least being a little careful— don’t make obvious mistakes like installing latest/nightly packages automatically, etc.
Re: VSCode, Dev Containers and Docker
#148...or you could use https://codeanywhere.com/ https://gitpod.io/ https://codesandbox.io/ https://codenvy.com/ for a more streamlined experience...
Unless, unimaginably, you need to keep your code on-prem... I know, I know. Unthinkable.
I haven't tested, but I think gitpod works with on-prem installations.
Re: VSCode, Dev Containers and Docker
#149Earlier quoted context omitted.
I guess the OP meant such that apt/yum/dnf/whatever runs every time the image runs, rather than just once when it's built. Not that that's something I see very often, mind.
Isn’t the standard approach here then to derive from base images, which have exact versions? Being honest, I’m not a Docker/VM legend but I’ve seen a few attempts at managing this, and base images was one of them. Personally, I don’t see the issue with it if you’re at least being a little careful— don’t make obvious mistakes like installing latest/nightly packages automatically, etc.
Yes, that's the standard approach, but the base images are frequently updated. If you really want to pin at a specific image, you need to specify the image hash, rather than using the "latest", or even a version tag (e.g. "2.1").
In your image that extends from the base image, you'll typically update the package repo cache (it is typically cleared after building the base image, to reduce the size), then install whatever packages you want.
Like you, I don't see a particular issue with updating system-level packages - especially from a security standpoint.
Re: VSCode, Dev Containers and Docker
#150Earlier quoted context omitted.
We also use remote dev boxes, but can VSCode connect to a remote server and connect to remote docker containers? For example, I don't have ruby installed on the remote dev box, but it is installed inside docker on the remote host. I also don't have ruby or docker running locally. I think all the linting plugins either expect ruby to be available on the remote host, or inside docker, but not this combo... Is there som…
> can VSCode connect to a remote server and connect to remote docker containers? Yes, it can. https://code.visualstudio.com/docs/remote/containers-advance... talks about setting it up.
Thank you! looks cool. Hope I’ll figure it out, considering I’m pretty clueless about VSCode