waveterm icon indicating copy to clipboard operation
waveterm copied to clipboard

Containerize project : configure dockerfile and compose files

Open sujal-goswami opened this issue 1 year ago • 8 comments

resolve #740

For user to build this project using docker they need to fulfil the prerequisites:

Prerequistes

  • Docker Desktop or docker should be installed
  • WSL - Windows Subsystem for Linux (only for windows users)
  • should have X server installed in host machine if not have then can download from command sudo apt-get install x11-xserver-utils. to check its correct installation run xhost this should give output as
access control disabled, clients can connect from any host
LOCAL:
SI:localuser:wslg

demo image

wave

References

https://github.com/cypress-io/cypress-documentation/issues/5816 --no-sandbox error

sujal-goswami avatar Aug 25 '24 18:08 sujal-goswami

CLA assistant check
All committers have signed the CLA.

CLAassistant avatar Aug 25 '24 18:08 CLAassistant

Thank you for setting this up! Since this is for a dev container, I think the .dockerignore doesn't need to be as restrictive, since the developer may care about the .md, config, and Yarn files. Otherwise it looks good to me!

esimkowitz avatar Aug 25 '24 20:08 esimkowitz

Could you verify that this complies with the guidelines for the dev containers in the guide I linked (Developing inside a Container)? This one may also be helpful: Create a development container. I think you can skip setting a CMD to start on container run, since this is not necessary for developing inside a container. Also I realize the suggested changes I made left a bunch of new lines, could you clean those up?

esimkowitz avatar Aug 26 '24 20:08 esimkowitz

Sure !

sujal-goswami avatar Aug 27 '24 04:08 sujal-goswami

now I think it is good to go; now, the user can use the VS Code dev container feature for seamless development in the container with pre-install go , eslint and prettier extensions in it.

sujal-goswami avatar Aug 27 '24 18:08 sujal-goswami

I don't think you need to build the app at all in the dockerfile, since it's fast enough. Also, because webpack-watch is blocking, the dockerfile never completes. I moved this to the "postStartCommand" in devcontainer.json, but I'm still unable to launch the app, as it's complaining about DBus not being started. I tried moving the service dbus start command to the postStartCommand too, but it's still not working. What host OS are you using to test this? I'm on macOS 14.

I'm concerned that if the devcontainer isn't reliable on all platforms or requires additional hoops to get working, it won't be that much better than just installing the deps directly. Aside from scripthaus, we don't have any crazy dependencies. We're also in the process of a pretty large rearchitecting and we're removing the scripthaus dependency as part of this, so our dependency story will get a lot simpler.

esimkowitz avatar Aug 28 '24 19:08 esimkowitz

I don't think the host OS is the issue here. It's more likely an issue with the dbus service. I encountered a similar dbus error during my testing but resolved it by running service dbus start on the machine. You can refer to this link for more details. By the way, I'm using Windows as the host OS, so it's odd if the OS is indeed the problem. The rearchitecting plan sounds great! Simplifying the dependencies will definitely streamline the process.

sujal-goswami avatar Aug 29 '24 11:08 sujal-goswami

FWIW, I did something similar as this PR - but, my goal was to build waveterm in a container - not run it in the container.

I purposely do not install multiple tool chains, project specific dependencies, etc. on localhost.

FYI, I am running on Fedora 41 and typically use VS Code (although I have been using emacs -nw again lately.

I concur that .devcontainer might be of dubious value, and there are several missing extensions that I typically use for web dev (vscode-tailwindcss, etc.). So I would probably just create my own.

In my case, I chose fedora:41 as the base OCI image because I wanted to be sure the resulting binary would run on my system.

That is not an issue when running in a container. If I was looking for containerization, I would prefer flatpak as an execution env because it is a more natural fit with my use of Fedora.

I suspect there may be a number of personal preferences out there.

But agree with @esimkowitz - thanks for putting in the effort. I am sure there are devs out there who can benefit.

klmcwhirter avatar Nov 19 '24 21:11 klmcwhirter

Closing this PR for now, sorry we couldn't get it merged

esimkowitz avatar Dec 23 '24 18:12 esimkowitz