I noticed the

coder workspaces [create]

commands no longer work and it's all root level (

coder [create]

). Is there any reason we can't support both?

I'm pretty sure it was supposed to be both.

@kyle any thoughts here ^

We can do both, but I'm not sure why we would. It makes docs and general usage a bit more confusing.

Experimenting with an Orka cluster and Coder https://orkadocs.macstadium.com/docs

Does it make them more confusing? This is exactly what you can do with git aliases, only git makes you alias

ci

yourself every freaking time instead of setting a sensible default. I guess we could go that route and have a customizable aliasing system with sensible defaults, but that's clearly beyond what's minimally viable. Regardless, if our customers can understand git, I don't think this will trouble them.

@Ironhide are you hoping to improve anything with your current system? we have a Docker example so you could install Coder on a DigitalOcean VM and provision containers but that seems to match what you said you already have.

Yeah what I am hoping to improve is to be able to "centrally manage" the containers/instances (or what ever the term is). Right now each is basically just a branch of https://github.com/Zate/ide (for example the n and t branches are for my kids and are on n.zate.org and t.zate.org). I host my own stuff on ide.zate.org and what I am hoping to get to is ide.zate.org/z and ide.zate.org/n and ide.zate.org/t - or alternatively z.ide.zate.org etc. Either works for me. But being able to spin up and down a new container that is managed centrally is what I am hoping for. From what I think I read, that is functionality in v2?

v2 does exactly that. We're still working on the web apps and naming convention (I believe it will be

/username/workspace_name/app_name

). SSH (vim/VS Code Remote) works now You can also parameterize workspaces so that each workspace can specify a different image, or start script, for example. Here's a link to the quickstart, you can install on your VM and use the Docker template: https://github.com/coder/coder#installing-coder

Played around quite a bit this weekend. I am trying to get a feel for what the architectural designs and intended use patterns are. I'm attempting to build out a basic docker-compose.yml with a coder-server and coder-pgsql - with the coder-server having access to the docker.sock of the VM it's running on. The general idea is that it'd be a main / admin container, and then spin up other containers inside the single node (initially) docker swarm its on. I'm not quite sure how this works if I am not installing the main server on the VM, but inside a container, and expecting it to setup peer containers when I spin up a workspace. Will I need a different/custom kind of terraform template? or will docker-local work do you think? I'm hoping to get it working with traefik etc also so that the server is on the public network to be proxied, and the containers and pgsql are on the internal net. Or will i need the workspace containers on the public net? what proxies those to the myserver/com/{user}/{workspace} (or similar)?

I modified the Docker local example to build images on the host instead of pulling from a registry. With this, it's very quick to iterate on new images and roll out updates. I'd probably still recommend using a registry and ci/cd for serious use cases 😉 https://gist.github.com/bpmct/badcccb259129870f4ad6a65b33f4565 (change

armv7

in main.tf to your architecture. I was testing on a Raspberry Pi)

sh
 docker run --rm -it \
   -e CODER_DEV_MODE=true \
   -v /var/run/docker.sock:/var/run/docker.sock \
   ghcr.io/coder/coder:v0.5.6

🎉 Should work on any OS or arch (including raspberry pi)

So Coder v2 will never really be useful running on localhost or 127.0.0.1 because the agent on workspaces will try to dial itself instead of the control plane. Any ideas here? Perhaps display a warning? I proposed adding support for the

--dev

tunnel without with in-memory DB requirement here https://github.com/coder/coder/issues/1176 but I understand this increases the maintenance burden as well as adds a requirement to persists URLs across restarts

Do you use a dotfiles repo? 🟢 = yes 🔴 = no

I noticed all workspaces are displayed in the template page but when I try to access non authorized ones I see an error. Should we display only the workspaces the user has access?

ssh port forwarding is helpful for accessing code-server (VS Code in a browser) and testing a running app, from a v2 workspace (in this case, docker-local, but it could be a Linux VM with Docker and a container) I installed code-server 4.4.0 (VS Code 1.66.2) into an image on DockerHub, and added that to the docker-local template and coder templates update... After building the workspace (coder create) 1. coder config-ssh 2. ssh port forward 8080 ssh -L 8080:localhost:8080 coder.mark-docker-ws -L 3000:localhost:3000 coder.mark-docker-ws 3. and start code-server with: /usr/lib/code-server/bin/code-server --host 0.0.0.0 --port 8080 --auth=none 4. I cloned a simple node app and started it on port 3000 5. opened VS Code (code-server) at http://localhost:8080 6. opened the node app at http://localhost:3000 Resources: Screenshot of Dockerfile installing code-server into the image code-server image I pushed to DockerHub (I change these frequently so use at your own risk) https://hub.docker.com/repository/docker/marktmilligan/code-server

I have a PR in progress that adds proper port-forwarding via

coder port-forward

with support for TCP, UDP and unix forwarding

you can also do multiple port forwards in a single SSH command by just specifying -L twice

Looking forward to seeing the new functionality

I guess when the devurls PR is merged then using code-server with coder v2 is going to be so so amazing 🙂 I actually can't wait to use it for my private "prod" setup 😄

Does the coder v2 cli provide some kind of non interactive mode and api tokens? I would like to build a CI/CD process to import templates have coder create a rollout to test the template and then update the prod version of it. At least thats the plan.

I guess thats out of scope but what do you thinkg of adding coder templates lint to lint the terraform files for best practieses and maybe coder specific features.

For now you can use a CLI token (that you get with

coder login

) in a CI/CD process! There isn't a way to set the token for the config yet though, and we should certainly add that. Feel free to open an issue!

It'll get slightly easier to iterate on templates in the coming weeks, which may resolve some of this. What all did you have in mind?

> I would like to build a CI/CD process to import templates have coder create a rollout to test the template and then update the prod version of it. At least thats the plan. We'll probably want to do this for our example templates too! See https://github.com/coder/coder/issues/1383 (well this is nightly, but should also apply as a test for template changes)

Well my initial idea was that the coder cli could just implement a normal terraform linter like tflint. And maybe give tips when the linter for example detect if the coder module is missing.

this is a great idea imo

Ahh neato!

I've opened a PR for this - https://github.com/coder/coder/pull/1483

Seems like the CLI is crashing when just running coder update 😄 I guess it should just print the help menu instead.