Code Server (Vs code online)
-
Does this have any sort of auth built in? Might be worth looking into the proxyAuth addon.
-
I have packaged a new app: A Visual Studio Code version that runs in the browser.
Here is the code: https://git.cloudron.io/dswd/vscode-app
The app works and already runs on my instance, but there are no tests yet.
I would like to submit the app to the appstore (for others to test and use) but currently I have a problem with the docker repository. Apparently I can only submit apps that are hosted on the Cloudron repo but I don't know how to push there.
-
The posts appear out of order, sorry about that
For some reason, NodeBB has no way to merge two topics together... Oh well.@dswd said in Code Server (Vs code online):
@girish Should I move the code back to my repo or should it stay on the cloudron git, or do you want to take over maintenance to make it an official app? How do you do this normally?
It can stay on Cloudron git. I will have a look once I have some time and move/fork it into the cloudron namespace. I will then give you maintainer status in that repo, so you can push directly. Only limitation is that you have to let us know whenever you want to push a new release to appstore. We hope to get this part automated in our CI/CD at some point (though, we are not working on this right now, so no ETA yet).
-
Does this have any sort of auth built in? Might be worth looking into the proxyAuth addon.
@atrilahiji said in Code Server (Vs code online):
Does this have any sort of auth built in? Might be worth looking into the proxyAuth addon.
Yes code server comes with a simple passwort auth. You can disable it and roll your own if you want to. It is not super helpful to integrate it with Cloudron LDAP as all users share one IDE but you can have a single password if you want to.
I will have a look into optional proxyAuth, however.
-
I'd like to point out I have a build of this running as well with a bunch of IDEs and SDKs added.
@dswd - would we be able to merge our projects together so there is not 2 vastly different builds floating about?
@murgero said in Code Server (Vs code online):
@dswd - would we be able to merge our projects together so there is not 2 vastly different builds floating about?
I am sorry, I was not aware of your app since it was not on the app store. Otherwise I would have used it and maybe sent a PR.
We should compare our approaches and select the best parts of each. Where is your code located? -
@murgero said in Code Server (Vs code online):
@dswd - would we be able to merge our projects together so there is not 2 vastly different builds floating about?
I am sorry, I was not aware of your app since it was not on the app store. Otherwise I would have used it and maybe sent a PR.
We should compare our approaches and select the best parts of each. Where is your code located? -
Does this have any sort of auth built in? Might be worth looking into the proxyAuth addon.
-
Mine is here: https://github.com/mitchellurgero/cloudron-vscode-package
I plan to move it to Cloudron's GitLab once they approve it for testing.
@murgero
I checked your image. It seems to install lots of packages that are not needed for code server (e.g. Apache and PHP). Also it adds some plugins that I don't think are required (sendmail, mysql and redis).
I suggest using my image as base because it seems more minimal. Can you test it and check if there is any functionality missing that I could add? -
@murgero
I checked your image. It seems to install lots of packages that are not needed for code server (e.g. Apache and PHP). Also it adds some plugins that I don't think are required (sendmail, mysql and redis).
I suggest using my image as base because it seems more minimal. Can you test it and check if there is any functionality missing that I could add?@dswd I can respect the opinion, but I use the addons mentioned as well as the adding different IDEs/SDKs (PS, PHP, Go, Rust, R-Lang, etc etc etc ) as users can't install linux packages on an app once it's installed. I also have build-tools to compile code, and I don't think apache is still there (I ended up choosing to use code-servers built-in proxy instead. So if apache is still being installed I will probably remove it in the future. Sendmail is used for testing and sending email from compiled apps, redis is kept for apps that would require it, and mysql (and other DBs) are thrown in because compiled apps may need a test DB to connect to.
It's kinda bloated when you first look at it, but users cannot modify what linux packages are installed and they cannot modify what cloudron addons are installed once code-server is installed.
That said, yes, technically speaking code-server doesn't need all this, but it's barely an IDE without the ability to actually use the code you write in it. So I included all the popular ones.
Minimal in this case I don't believe works. Sure yours takes up less space but my package includes more features. In this case, I think keeping our apps separated for now is the best course of action.
This is not to say I don't like what you did. There is something to be said about a minimal-first approach to building an app. I think - let's keep building our packages separate and we can talk to @girish / @nebulon about how to add both (potentially) to the app store. Maybe just labeled differently so the admins can choose how they like to build.
And if we do go that route I would like to work together to make the login process the same on both apps - to help make it seamless to the end-users.
What do you think? I am also open to suggestions.
Edit: I hope none of this comes off as negative towards your package. That is not my intent. It's clear you and I both have a want/need/passion for code-server to be on the store. I am just genuinely excited to have this conversation with someone other than myself.
-
@dswd I can respect the opinion, but I use the addons mentioned as well as the adding different IDEs/SDKs (PS, PHP, Go, Rust, R-Lang, etc etc etc ) as users can't install linux packages on an app once it's installed. I also have build-tools to compile code, and I don't think apache is still there (I ended up choosing to use code-servers built-in proxy instead. So if apache is still being installed I will probably remove it in the future. Sendmail is used for testing and sending email from compiled apps, redis is kept for apps that would require it, and mysql (and other DBs) are thrown in because compiled apps may need a test DB to connect to.
It's kinda bloated when you first look at it, but users cannot modify what linux packages are installed and they cannot modify what cloudron addons are installed once code-server is installed.
That said, yes, technically speaking code-server doesn't need all this, but it's barely an IDE without the ability to actually use the code you write in it. So I included all the popular ones.
Minimal in this case I don't believe works. Sure yours takes up less space but my package includes more features. In this case, I think keeping our apps separated for now is the best course of action.
This is not to say I don't like what you did. There is something to be said about a minimal-first approach to building an app. I think - let's keep building our packages separate and we can talk to @girish / @nebulon about how to add both (potentially) to the app store. Maybe just labeled differently so the admins can choose how they like to build.
And if we do go that route I would like to work together to make the login process the same on both apps - to help make it seamless to the end-users.
What do you think? I am also open to suggestions.
Edit: I hope none of this comes off as negative towards your package. That is not my intent. It's clear you and I both have a want/need/passion for code-server to be on the store. I am just genuinely excited to have this conversation with someone other than myself.
@murgero
I can see your point. You are providing those dependencies to users just in case they need them (and because you need them). I agree, not being able to install packages is kind of a problem. However, a lot of software (e.g. nodejs, rust and php) can be installed into the user space.
I decided against putting in more dependencies because I don't want to monitor so many dependencies for security issues and push new releases every other day.
I too think it would be best to keep the versions separate as you require those dependencies.
Oh and no, your comment does not come off as negative (hope mine doesn't either). We just have different approaches. -
@dswd I can respect the opinion, but I use the addons mentioned as well as the adding different IDEs/SDKs (PS, PHP, Go, Rust, R-Lang, etc etc etc ) as users can't install linux packages on an app once it's installed. I also have build-tools to compile code, and I don't think apache is still there (I ended up choosing to use code-servers built-in proxy instead. So if apache is still being installed I will probably remove it in the future. Sendmail is used for testing and sending email from compiled apps, redis is kept for apps that would require it, and mysql (and other DBs) are thrown in because compiled apps may need a test DB to connect to.
It's kinda bloated when you first look at it, but users cannot modify what linux packages are installed and they cannot modify what cloudron addons are installed once code-server is installed.
That said, yes, technically speaking code-server doesn't need all this, but it's barely an IDE without the ability to actually use the code you write in it. So I included all the popular ones.
Minimal in this case I don't believe works. Sure yours takes up less space but my package includes more features. In this case, I think keeping our apps separated for now is the best course of action.
This is not to say I don't like what you did. There is something to be said about a minimal-first approach to building an app. I think - let's keep building our packages separate and we can talk to @girish / @nebulon about how to add both (potentially) to the app store. Maybe just labeled differently so the admins can choose how they like to build.
And if we do go that route I would like to work together to make the login process the same on both apps - to help make it seamless to the end-users.
What do you think? I am also open to suggestions.
Edit: I hope none of this comes off as negative towards your package. That is not my intent. It's clear you and I both have a want/need/passion for code-server to be on the store. I am just genuinely excited to have this conversation with someone other than myself.
@murgero
I think I found a way to get around the read-only root and install additional software. I added a script that will fetch and install a minimal Linux and chroot into it:chroot-alpine.
Inside it you can install additional software as you like. You can also use the same method to run Ubuntu instead of Alpine Linux but that will use much more storage. -
The other option here is to use something like Sysbox to enable DockerInDocker (DinD) type functionality, which can then separate and isolate the addon services needed for dev/test in a nested way, keeping the app lean.
-
I think we should collaborate on a minimal base docker image that only contains the installation of code-server, and then design a solution to allow adding dev dependencies on top of it as required by each end-user.
Say, first lift all the code-server-specific improvements from murgero's image into dswd's image and publish it at
cloudron/code-server-base. Then murgero's image starts withFROM cloudron/code-server-baseand adds their unique dev dependencies and publishes it separately. The key will be improve the image build, installation, and updating process to be as smooth as the usual app install process. (The cli is great for cloudron development, but kinda cumbersome for ongoing maintenance.)Based on the way code-server is designed I doubt it could ever be a multi-user app. There is some discussion on code-server multi-tenancy on Setting up code-server for multi-tenancy #792. In summary, it doesn't seem viable and the discussion quickly shifts towards how to set up and manage a container-per-user design, which is an area that I think Cloudron could add a lot of value.
Perhaps both of these problems could be solved by creating a custom app that uses the cloudron api to expose an easier way to spin up code-server apps for users on demand, using the images designated by the admin.
code-server is a good use-case for proxyAuth. I think it would be neat if we could forward some path to a port inside the container to allow users to hit a dev web server running inside.
-
I think we should collaborate on a minimal base docker image that only contains the installation of code-server, and then design a solution to allow adding dev dependencies on top of it as required by each end-user.
Say, first lift all the code-server-specific improvements from murgero's image into dswd's image and publish it at
cloudron/code-server-base. Then murgero's image starts withFROM cloudron/code-server-baseand adds their unique dev dependencies and publishes it separately. The key will be improve the image build, installation, and updating process to be as smooth as the usual app install process. (The cli is great for cloudron development, but kinda cumbersome for ongoing maintenance.)Based on the way code-server is designed I doubt it could ever be a multi-user app. There is some discussion on code-server multi-tenancy on Setting up code-server for multi-tenancy #792. In summary, it doesn't seem viable and the discussion quickly shifts towards how to set up and manage a container-per-user design, which is an area that I think Cloudron could add a lot of value.
Perhaps both of these problems could be solved by creating a custom app that uses the cloudron api to expose an easier way to spin up code-server apps for users on demand, using the images designated by the admin.
code-server is a good use-case for proxyAuth. I think it would be neat if we could forward some path to a port inside the container to allow users to hit a dev web server running inside.
@infogulch
My current code already uses proxyAuth and adds TCP and UDP ports for dev that you can freely assign.
Please tell me what you think is missing and I will add it. -
I think we should collaborate on a minimal base docker image that only contains the installation of code-server, and then design a solution to allow adding dev dependencies on top of it as required by each end-user.
Say, first lift all the code-server-specific improvements from murgero's image into dswd's image and publish it at
cloudron/code-server-base. Then murgero's image starts withFROM cloudron/code-server-baseand adds their unique dev dependencies and publishes it separately. The key will be improve the image build, installation, and updating process to be as smooth as the usual app install process. (The cli is great for cloudron development, but kinda cumbersome for ongoing maintenance.)Based on the way code-server is designed I doubt it could ever be a multi-user app. There is some discussion on code-server multi-tenancy on Setting up code-server for multi-tenancy #792. In summary, it doesn't seem viable and the discussion quickly shifts towards how to set up and manage a container-per-user design, which is an area that I think Cloudron could add a lot of value.
Perhaps both of these problems could be solved by creating a custom app that uses the cloudron api to expose an easier way to spin up code-server apps for users on demand, using the images designated by the admin.
code-server is a good use-case for proxyAuth. I think it would be neat if we could forward some path to a port inside the container to allow users to hit a dev web server running inside.
@infogulch said in Code Server (Vs code online):
I think it would be neat if we could forward some path to a port inside the container to allow users to hit a dev web server running inside.
code-server natively supports this already, just simply logging in and then browsing to
https://fqdn-of-app/proxy/portNumberexample:https://vscode.example.com/proxy/8080would put you on port 8080 inside the app. So if you had an app or something running on that port, it's http data would be displayed like normal.--
https://urgero.org
~ Professional Nerd. Freelance Programmer. ~ -
@infogulch said in Code Server (Vs code online):
I think it would be neat if we could forward some path to a port inside the container to allow users to hit a dev web server running inside.
code-server natively supports this already, just simply logging in and then browsing to
https://fqdn-of-app/proxy/portNumberexample:https://vscode.example.com/proxy/8080would put you on port 8080 inside the app. So if you had an app or something running on that port, it's http data would be displayed like normal.@murgero said in Code Server (Vs code online):
code-server natively supports this already ...
https://fqdn-of-app/proxy/portNumberOh neat, I'm glad they landed on that, that's a good solution. Perhaps a proxyAuth implementation should exclude the proxy path with something like
"proxyAuth": { "path": "!/proxy" }.Perhaps this is a bit to early to worry about, but at some point we might consider restricting the app proxy's access to cloudron cookies with domain or path parameters.
-
@murgero @dswd what are the extra packages that are pre-installed? If it's not too big, maybe we can compromise and just install it all in one. It's more important to be useful to more number people than be minimal (of course, everything has a limit..).
I wonder if the right approach here is something like JupyterHub. What that project does is to have a "workspace manager" with a login screen. When logged in, it spins up a new "notebook docker container" for each user. This way the user can install whatever packages they want in that docker image. See https://github.com/jupyterhub/jupyterhub . I guess in our case if the size is limiting, maybe we should write a VsCodeHub which when logged in, spins off a vs code container for each user. This makes the app properly multi-user.
