I need to get a local Redis server running for development purposes. What would the “happy path” be for this Bluefin/Aurora?
Should I install via brew and run it that way? Or would this sort of thing be better done in a devcontainer via VSCode? Distrobox?
Basically, I am trying to figure out the “best” way to do this in the ublue family… Thanks!
For development purposes the best way would either be via devcontainer or distrobox (or your own docker/podman container), depending on what you prefer. Reason is that with homebrew you have little control over versioning. Homebrew is meant for cli applications that should be better intergrated than Distrobox
The Distrobox route… Is there a way to attach the host-installed VSCode to the Distrobox container? All the guidance I have been able to find so far is to install VSCode again inside the Distrobox container.
I kind of don’t want to do that since VSCode is already on the host system!
You can, but you have to either change distrobox to use docker or change the docker path in vscode to “podman”. Devcontainers is probably easier
OK… I am trying to do this in a devcontainer.
I have golang devcontainer running with “redis-homebrew” also installed. I need to be able to get to a bash shell inside the devcontainer so I can interact with the Redis server (a “redis-cli ping”, etc…).
I have installed the devcontainer CLI and added it to my path. But I cannot seem to actually get into the running devcontainer, getting the error message that the devcontainer is not found.
Can anyone point me to some documentation to hack my way out of this?
Controversial opinion, but I find devcontainers, distroboxes and toolboxes a pain in the ass for local development and spend as much time debugging them as developing, personally. I therefore run redis, psql, nvm, rvm, etc through brew fwiw. Homebrew is considered to also be a happy path for “cli tools” for local development on bluefin/aurora I believe? And if I need to reset, Homebrew is pretty easy to reset.
When deploying to a remote server, I definitely do use containers proper (Docker) though.
Yeah…
I really like the concept of using devcontainers in VSCode but I seem to run into walls whenever I try to use them for anything more than something pretty basic… at which point, you don’t really need a devcontainer at all.
My best use of Distrobox so far has been getting an old Windows game running in Lutris when I has having trouble with it in the Lutris flatpak.
Personally, I am used to the (at this point) “traditional” Docker workflow. I suppose could do that on Aurora/Bluefin but… at that point why not just use a more traditional distro where, due to experience to be fair, there would be less friction involved? It might help if I knew more about Podman in terms of using devcontainers on Aurora/Bluefin?
At the risk of saying something good about Windows… I kind of wish that using Distrobox for development could be more like using WSL for development. I work in a Windows shop, and use WSL for development there. I can easily open VSCode in Windows but have it attached to WSL Ubuntu where my code is (locally) stored and executed. Need something installed in the Ubuntu environment for my code to interact with? Just sudo apt install it. Need systemd? WSL has it these days. I can, and do, run Docker inside WSL as needed.
It’s all pretty seamless though, to be fair, it’s a Microsoft text editor being used to connect to a Microsoft hypervisor, etc. I would love to be able to replicate this dev experience (with containers instead of a VM…) but with a Linux host system instead of a Windows one.
If there’s a way to do that here, I would love for that to be the case. But I do seem to frequently run into walls trying to make that happen and it’s nice to hear that I’m not the only one. 
We ship with the traditional docker workflow out of the box for a reason, it works the same on every OS, this is how you’re supposed to use it (not via a distrobox).
Ah… well, maybe I am making things harder for myself than they should be!
I suppose I have been trying to do things in the “blessed” way on Bluefin… or at least, what I believed the “blessed” way to be. But there’s a healthy amount of assuming happening on my part there, and we know where that usually gets us! 
I guess I was under the impression that I was “supposed” to use devcontainers (for instance) and was not “supposed” to do development directly on the host system - by which I mean that devcontainers are the intended workflow, etc. I realize, of course, that I can use the system any way I want, but I’ve been trying to be a good user and use it as (I thought it was) intended with… mixed results.
Part of that, I’m sure, is on me - I am used to doing things a certain way, re-learning takes time/effort, etc. I have no doubt that, in many cases, I am “holding it wrong” as Apple once infamously said…
I’m working with an artist on the graphic for this. But you don’t need to use devcontainers if you don’t want to, that’s just what we recommend.
I just ran through their quickstart and that works fine too: Run Redis Stack on Docker | Docs
Devcontainers are just an extension of Docker. My devcontainer.json is usually very small and I do most of the stuff on Dockerfile anyway. The only reason to do devcontainer instead (as a solo dev) is just to have your IDE check everything inside of your container using the runtime of your container.
My usual pattern is to develop directly on my local host. I usually find things like nvm or Python virtual environments (or similar) to be sufficient for dependency management.
If the app is destined to be deployed as a docker container, I’ll have a dockerfile in the repo. But I don’t usually develop inside the container, per se. I will run the container locally for testing, etc.
And maybe that’s where I am getting a little mixed up with devcontainers in VSCode. I thought devcontainers were intended for you to develop directly inside them. Is that not so?
If so, I would be happy to do that - I really like the concept of having a self-contained dev environment per project - but that is tricky when I can’t seem to get to a bash prompt inside the dev container to run/test things.
But maybe that’s not what it’s for and I am totally confused!
This seems really weird. Because normally VSCode should automatically build and enter the Devcontainer as soon as it sees the file inside of your repo.
So, how do I get to a bash prompt and how do I know that I am inside the container in the devcontainer implementation?
Does VSCode tell you that you are inside of a remote connection? (Bottom Left)
It does.
Oh… I may be an idiot. I need to use the terminal inside VSCode, don’t I. My long time habit is to NOT do that. I have always used the native terminal…
Hahah I was already confused. Btw you probably dont want to do your Redis configuration inside of the terminal but rather append the necessary commands to your Dockerfile because otherwise you need to reconfigure it everytime something changes.
Oh, yeah. I’m not doing configurations via the terminal. I just want the ability to run certain redis-cli commands during development.
When I run devcontainer exec in the root directory of my project in the host terminal, I get the following error:
❯ devcontainer exec
[105 ms] Error: Dev container not found.
at Ka (/var/home/$USER/.vscode/extensions/ms-vscode-remote.remote-containers-0.388.0/dist/spec-node/devContainersSpecCLI.js:471:768)
at tl (/var/home/$USER/.vscode/extensions/ms-vscode-remote.remote-containers-0.388.0/dist/spec-node/devContainersSpecCLI.js:668:6034)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
at async OrA (/var/home/$USER/.vscode/extensions/ms-vscode-remote.remote-containers-0.388.0/dist/spec-node/devContainersSpecCLI.js:668:3703)
at async /var/home/$USER/.vscode/extensions/ms-vscode-remote.remote-containers-0.388.0/dist/spec-node/devContainersSpecCLI.js:482:1190
EDIT - Oh… Am I supposed to use devcontainer open instead?
EDIT 2 - If I preface every command with devcontainer exec from the host terminal (Ptyxis, of course!), it works… A little tedious, but it works. It would be nice if there an were an easy way to avoid that.
I cannot help you with the cli tbh, I always let WebStorm handle everything 