-
Notifications
You must be signed in to change notification settings - Fork 6.3k
Declarative Configuration #3534
-
First of all, thanks for this great project! It really changed how I look at development environments.
I come from a very mixed development and operational background. Having run kubernetes since pre 1.0 on bare metal (I know, what was I thinking) I've gained a deep appreciation for declarative APIs and configuration. So, having just wiped my machine and installed Fedora 34 (which is really slick) I decided to try to do all development in code-server running on a kubernetes cluster.
Being the person that I am I've been playing with building manifests slowly checking out how to do things and add configuration as I go only needing kubectl apply -f <files>
to deploy code-server (or rather let ArgoCD do it for me) but now I'm running into problems with configuring code-server itself. There are two big things that I want to hold off on as long as possible and that is introducing volumes for persistent storage and rebuilding and storing customized container images.
There are three categories that I'm interested in to see what solutions people have found:
-
Package installation on start.
People need tools and some of the things I tend to install immediately on boot of a new pod are things like, vim, openssh-server, ripgrep, fdfind, bat, kubectl, the list goes on. How do people deal with declaring what packages are expected to be installed? A simple script that you have to run manually? -
Extension installation on start.
Same idea but with the extensions. As fast as I am with vim keybindings, I've crippled myself by not being able to use anything else. Next to the--install-extension
flag I haven't found any other way of automatically installing extensions on boot appart from the Settings Sync plugin which requires GitHub gists. My initial thought was that because everything in~/.config/code-server/config.yaml
represents a command-line flag I could just create a yaml list of extensions which correctly gets translated to--install-extension ext1,ext2,ext3
and it would install those when the server starts. Sadly it can't deal with lists and also it is an action by itself which means that it doesn't start the server making the pods crash. Again what have people found to be useful? -
User settings.
This one might be the easiest as it probably means just mounting a folder from a configMap/secret in the correct location in the pod.
As said I'm very interested in tricks people have found and in the visions of the maintainers before I start hacking away at things!
Beta Was this translation helpful? Give feedback.
All reactions
Great questions!
- Usually people just extend the image and add
apt-get
(or equivalent) commands, then use the resulting image for development. You could create a cronjob that builds this image every day and pushes it to a local registry inside your k8s cluster. - You could either install the extensions into the image, or if you want portability you could create an initContainer in your Pod that reads a list of extensions from a ConfigMap and calls
code-server --install-extension
with a PVC for wherever the extensions are installed (probably~/.local/share/code-server
or something). - Yep!
Replies: 1 comment 1 reply
-
Great questions!
- Usually people just extend the image and add
apt-get
(or equivalent) commands, then use the resulting image for development. You could create a cronjob that builds this image every day and pushes it to a local registry inside your k8s cluster. - You could either install the extensions into the image, or if you want portability you could create an initContainer in your Pod that reads a list of extensions from a ConfigMap and calls
code-server --install-extension
with a PVC for wherever the extensions are installed (probably~/.local/share/code-server
or something). - Yep!
Beta Was this translation helpful? Give feedback.
All reactions
-
❤️ 1
-
Thanks @deansheather. The init container approach is definitely a way to do it for the extensions, too bad It won't work with the os native packages. As I said I'd like to avoid rebuilds but I understand that people would go for it. I wonder if something like cloud-init would work here. If it's installed in the image by default, people can just add the cloud-config file and if the startup script detects it it will just run.
Beta Was this translation helpful? Give feedback.