191–200 of 234 posts
Earlier quoted context omitted.
Is not docker server running inside a VM though ? You could also run Xserver (available on both Mac and Windows) and ssh -X into a VM to run GUI apps inside the VM.
> Is not docker server running inside a VM though No, docker server runs directly on top of the OS as a native program. As for Docker containers managed by the Docker server, they are runing on top of a supervisor - not in a full VM.
I'm not quite sure that I understand the advantages of doing development work inside of the container. What am I missing?
Earlier quoted context omitted.
I don't think so. If fact you could just package your "CLI driven workflow" up into a docker image and now you can instantly move it between machines, peers, etc... Furthermore you could version and manage the evolution/drift of your workflow as underlying components change/get updated.
Exactly: I have CI produce a Docker image from my dotfiles repo https://bergie.iki.fi/blog/docker-developer-shell/
A little bit off-topic, but I hope it's relevant enough: can someone who's well-versed in Docker give me some pointers as to how I can use it in a better way? Let me elaborate. I'm a bit of an old fart when it comes to software development. I prefer stable, slowly evolving solutions. I am a fan of the role of classical distributions. I abhor bundling every piece of software with all its particular versioned dependenc…
You have an increasingly rarefied perspective, and you should hang onto it. Docker is a treadmill. Docker leads to Docker Compose leads to Kubernetes leads to whatever. It's a lot of noise and motion; you will increasingly encounter engineers who grew up on this stuff and assume it as a prerequisite, and are eager to climb the treadmill, thinking it's a ladder. You know about other options, and can decide when to sto…
Earlier quoted context omitted.
Working with a team on a project with a moderately complex build process (say python and node), it soon becomes a painful to onboard new team members and get their dev environments set up. Even assuming they have the same version of macOS, homebrew constantly evolves so getting everyone developing with the same version of dependencies as you use in prod is super painful. If they’re on Linux they likely don’t run the…
Python and node are probably the easiest to get setup. With Python you have venvs which do a lot of the heavy lifting required. The issue becomes when you are on a non Linux environment for development and deploy to Linux in containers. If you build your code locally then you are debugging $DESKTOP issues which might not be the same as Linux. Also languange environments with poor dependency management (e.g. C, C++) b…
setting up pyenv, correct version of python manually, nvm, postgres, etc.. takes time and our setup guides grown a lot in the past 5 years...,
with containers all those long setup guides can boil down to `docker-compose up -d`
Earlier quoted context omitted.
"3 versions of a framework" is quite vague. Are those versions Linux/Windows/Mac? Because then Docker is not very useful. Docker is not a general solution to this problem because it ties you intimately to Linux, whether directly, or through VMs, or compat layers.
Let's say you maintain or occasionally code several big webapps in Ruby. One uses Ruby 2.4 and Ruby-on-Rails 3.2, another uses Ruby 2.6 and Ruby-on-Rails 5.2, and the last one is bleeding edge using Ruby 3.0 and Rails 6.1 Having all versions of you language and framework installed top level is a huge pain in the ass, since they inevitably will interfere with each other. Having separate containers with all necessary d…
Earlier quoted context omitted.
Let's say you maintain or occasionally code several big webapps in Ruby. One uses Ruby 2.4 and Ruby-on-Rails 3.2, another uses Ruby 2.6 and Ruby-on-Rails 5.2, and the last one is bleeding edge using Ruby 3.0 and Rails 6.1 Having all versions of you language and framework installed top level is a huge pain in the ass, since they inevitably will interfere with each other. Having separate containers with all necessary d…
rbenv actually solves this quite well. You can set a project-level version in a .ruby-version file, and each lang version has its own gem cache
I don't use docker with any of these projects. They're mostly legacy for us at this point and are shipping to EC2 instances directly.
Our more current projects do use Docker, however, and we're doing development along side of Docker in those instances and that seems to be working fine for us.
I do appreciate that a dev container would / may be a better approach to this for other reasons and especially, potentially, other languages and ecosystems, though.
Earlier quoted context omitted.
Python and node are probably the easiest to get setup. With Python you have venvs which do a lot of the heavy lifting required. The issue becomes when you are on a non Linux environment for development and deploy to Linux in containers. If you build your code locally then you are debugging $DESKTOP issues which might not be the same as Linux. Also languange environments with poor dependency management (e.g. C, C++) b…
for me the best advantage of working with containers is the initial setup for new colleagues, especially junior devs..., setting up pyenv, correct version of python manually, nvm, postgres, etc.. takes time and our setup guides grown a lot in the past 5 years..., with containers all those long setup guides can boil down to `docker-compose up -d`
I do see value in it, though, after the comments and after doing some additional reading. I could see myself pushing this direction if the teams I worked on had higher churn rates or more frequent new hires. Also, I think that it lends itself well to certain tech stacks / languages / ecosystems than others.
Vscode can be problematic in that respect. Typically with dependencies used by an extension often assuming they can reach out to other servers.
I look at initial internet facing container creation as a separately managed snapshot process to grab dependencies which then gets configured for particular Dev, build, test, runtime and release containers that are built by the dependency collecting original container.
Ie something like vscode isn't installed in the internet facing container, it is installed in the offline build of a Dev container. This is where the difficulties lay in my approach.
Earlier quoted context omitted.
> 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 conta…