11–20 of 76 posts
This blog doesn't convince me why I should care about Hocus over solutions like VSCode devcontainer + Vagrant. That is more what it is competing with, not raw Docker/VM.
Earlier quoted context omitted.
Nix solves a different problem than Hocus. Nix lets you define a development environment, Hocus gives you a way to run it on a remote server. Right now we use Dockerfiles to let users define the packages they need in their dev env, but we would like to support Nix in the future too. Interestingly, you can use custom BuildKit syntax https://docs.docker.com/build/dockerfile/frontend/ to build Nix environments with Dock…
From what I can tell, devenv [1] and devbox [2] (both built on Nix) can also deploy to remote servers. [1] https://devenv.sh [2] https://www.jetpack.io/devbox
Whatever way you're using Nix for developer environments, you can reuse most of that work to define a package suitable for remote deployment.
Author doesn’t mention it but I wonder if tried or considered Nix/NixOS’s reproducible developer environments and ruled them out for any reason. I couldn’t tell from the article if there’s something unique to his requirements that disqualifies them. https://nixos.org/explore https://nix.dev/
Nix solves a different problem than Hocus. Nix lets you define a development environment, Hocus gives you a way to run it on a remote server. Right now we use Dockerfiles to let users define the packages they need in their dev env, but we would like to support Nix in the future too. Interestingly, you can use custom BuildKit syntax https://docs.docker.com/build/dockerfile/frontend/ to build Nix environments with Dock…
I don't really understand the point of a "dev box" that's hosted in a DC and shared, at all - at least not the way they're painting it here.
Hardware capabilities for even consumer level laptops and desktops have progressed much faster than average network connections.
Having testing/preview/branch named environments in a DC? Sure. But this line:
> They should be able to run any software they want inside their own workspaces without impacting each other.
What does that even mean?
Is this about someone working on a feature branch that uses some new dependency that needs to be installed?
That's 100% the sort of thing your local development environment is for, until you're ready to push it to your hosted test/whatever environment.
> But when it's running in a VM, the VM gobbles up as much memory as it can and, by itself, shows no inclination to give it back.
Someone, anyone, tell me which hypervisor doesn't enforce a memory limit on VMs?
Containers have their place, they can be great, but I've tried the whole "containerize everything" approach, and it's no less time consuming than not containers, and now you have another Thing You Have To Learn (TM).
This isn't to say that virtualization is a bad thing for a development environment. It can be a very good thing, actually, but you don't need containers. A development environment, in my opinion, should be well organized, easy for a new developer to pick up, but also scrappy and adaptable to new and interesting situations. Containers, at least in their current conception, are antithetical to this. They're best kept to deployments or running things in a scenario where you know for sure you're not going to tinker with anything. I don't think I've worked on a software project where, at some point or another, I didn't need to reach under the hood in some unconventional way to investigate an issue or simulate some circumstance. Yes, you can do those things with containers, but now you have to deal with that complexity, which can get in the way by merely being confusing and indirect.
Having given up on using containers for development, when I want to use virtualization, I just spin up minimalist instances of Debian under Qemu (using the UTM GUI). This way, I can run a Thing (TM) in isolation, easily open up a shell, or SSH into it from the host shell, or start a GUI from within it if I need to, or install however many services I want within it and open up ports to the host, or have shared folders, etc. etc. etc.
But what if I need multiple of a Thing (TM) running at the same time? In that case, I just clone the VM. No Dockerfiles, no docker-compose.yml, no "volumes", no orchestration, no images failing to build because reasons, no qcow2 files blowing up with Docker For Mac (though that situation has improved), no pruning of orphaned containers/images, no worrying about whether your container should only be running a single process/service, and so on.
The only drawback to this is that, if the host is Linux, then it's indeed kinda dumb to be running other Linux kernels in VMs. But hey, it's 2023 and the difference in performance may not be meaningful depending on what you're doing. I know that, on an M1 Mac, I can run graphical applications at monitor resolution with incredible speed (perhaps moreso with Parallels instead of Qemu), so I'd struggle to care about any performance drawback if my host was Linux on the same hardware.
I'm sure that, for some, containers in development will be totally worthwhile. But if they don't seem worthwhile to you, dear reader, then that's probably because they wouldn't be.
This whole article is weird to me. I don't really understand the point of a "dev box" that's hosted in a DC and shared, at all - at least not the way they're painting it here. Hardware capabilities for even consumer level laptops and desktops have progressed much faster than average network connections. Having testing/preview/branch named environments in a DC? Sure. But this line: > They should be able to run any sof…
https://code.visualstudio.com/docs/remote/ssh-tutorial
See also:
https://code.visualstudio.com/docs/devcontainers/containers
People pay for this.
This whole article is weird to me. I don't really understand the point of a "dev box" that's hosted in a DC and shared, at all - at least not the way they're painting it here. Hardware capabilities for even consumer level laptops and desktops have progressed much faster than average network connections. Having testing/preview/branch named environments in a DC? Sure. But this line: > They should be able to run any sof…
Consider exploring LXC for a more mature alternative to Docker. It's not confined to the OCI ecosystem and offers a higher degree of isolation for development environments.
I used to use WSL 2 or a VM, but on a Linux host LXD is a really nice workflow. I can create a fully isolated Linux instance with all my dev tooling on it (optionally script/automate the install of all my tools), and with nested containers enabled I can even run _Docker in that LXD container_ so that when I type `docker ps` on that instance, and `docker ps` on my host, they each have their own set of containers running. For example, I have an ElasticSearch and Redis instance running in the dev box but Syncthing on the host.
Then I can use snapshots to back up the dev environment, or blow it away completely once it gathers too much cruft all without affecting my host. It's really great.
Pair it with VS Code remote SSH and you have a very feature rich setup with little effort.
This whole article is weird to me. I don't really understand the point of a "dev box" that's hosted in a DC and shared, at all - at least not the way they're painting it here. Hardware capabilities for even consumer level laptops and desktops have progressed much faster than average network connections. Having testing/preview/branch named environments in a DC? Sure. But this line: > They should be able to run any sof…
Enterprise likes it, because it gives them more visibility and control over what's going on in the dev box. That gives more angles to control against e.g. exfiltration threats. It also makes dev environments much more homogeneous: you worry less about client machines. In principle you could have a fleet of stateless Chromebooks whose main function is ssh and http, all connecting to identical virtualized desktops that…
Virtualization means images means standardization means everyone is using the IDE and tools that IT and "Enterprise" decides.
It has it's pros and cons. But one of those cons is that it can make for an intolerable work environment. At least for me. I've gotten to the point where I now ask about dev environment during the interview process. If they mandate Mac or Visual Studio I'm not interested (not trying to start a flame war, those are my personal preferences). I know that certain organizations need their control for auditing, security and remote wipe reasons, and that is understandable. I'll just go work elsewhere. It's fine.