Code Server (Vs code online)
-
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.
-
@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.
My package includes a ton of extra packages to cover the most popular programming and scripting choices. (Some are actually already in the Cloudron base image, which I use.)
- GOLANG
- PHP7.4 (PHP8.0 will be included soon!)
- Python
- PowerShell
- DotNet Core (C#, VB.NET, etc) (.NET Full will be included soon as well since full supports Linux now I believe)
- R
- R-lang
- NodeJS (Updated to latest)
I am probably missing a couple but I wanted to make sure a lot of the popular stuff was covered here.
-
Hey everyone! I just did want to ask about the current progress on this package. Is there already a roadmap for an official release in the app store? Or is this still under heavy development?
-
@chilipp Currently still under development. You're more than welcome to test it out if you would like!
-
@chilipp Currently still under development. You're more than welcome to test it out if you would like!
