Take note of the command the container is running as well as the port mapping - 0.0.0.0:8080->80/tcp maps port 8080 on all host interfaces to port 80 inside the web1 container. The top line shows the new web1 container running NGINX. docker infoĬONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMESĤe0da45b0f16 nginx "nginx -g 'daemon. Run the docker info command and locate the list of network plugins. The docker info command shows a lot of interesting information about a Docker installation. Do not confuse this with the “bridge” driver. In the example above we are showing the configuration details for the network called “bridge”. NOTE: The syntax of the docker network inspect command is docker network inspect, where can be either network name or network ID. Maybe the labels they implement in 6.10 is only a small step in their plan towards this direction, who knows."Id": "3430ad6f20bf1486df2e5f64ddc93cc4ff95d81f59b6baea8a510ad500df2e57", But it would be an easy adaption from a compose file that I copy&paste from the internet. A so called compose based template would just predefine the unraid paths, as the current templates do. but that's something a "power-user" anyway has to deal with. I see the point with the storage location for volumes. It would also allow for people in the second group to to at least basic stuff in the GUI with their custom compose files. It would be a lot more compatible with custom compose files, especially that (at least my impression) a lot of users here use them. They would only need to support the features they want in the GUI and just but unraid specific stuff in labels (as with the comming changes for icon and webgui url).Įven if they would decide to support only one container in the GUI per compose file. I don't know their thoughts and plans, but I would be consequent and just replace the templates with compose-files. What I don't get is what's the plan with the step with the 6.10 feature of the container labels for just icons and webgui url. So that's why this kind of "compose - dev - container" works perfectly for me. the people which want most, if not all compose features, which usually also create their own compose files. the people which just want no special features, but reuse compose configs.Ģ. I think the main problem is that we have at least two use-cases for people using docker compose.ġ. RUN mkdir -p /config/custom-cont-init.d & \Įcho "code-server -user-data-dir /config/data -extensions-dir /config/extensions -install-extension ms-azuretools.vscode-docker" >/config/custom-cont-init.d/extensions.sh & \Įcho "code-server -user-data-dir /config/data -extensions-dir /config/extensions -install-extension mikestead.dotenv" >/config/custom-cont-init.d/extensions.sh & \Ĭhmod +x /config/custom-cont-init.d/extensions.sh etc/bash_completion" >/etc/bash.bashrc & \ usr/share/bash-completion/bash_completion" >/etc/bash.bashrc & \Įcho " elif then" >/etc/bash.bashrc & \Įcho ". # enable bash completion globally (we could uncomment existings lines but this is harder to automate)Įcho "# enable bash completion in interactive shells" >/etc/bash.bashrc & \Įcho "if ! shopt -oq posix then" >/etc/bash.bashrc & \Įcho " if then" >/etc/bash.bashrc & \Įcho ". RUN mkdir -p /usr/local/lib/docker/cli-plugins & \Ĭurl -fSL $/contrib/completion/bash/docker-compose \ to make it smaller.ĬOPY -from=docker /usr/local/bin/docker /usr/local/bin/ĪRG DOCKER_COMPOSE_SWITCH_VERSION="v1.0.2"ĪRG DOCKER_COMPOSE_COMPLETION_VERSION="1.29.2" env file in these commands (couldn't get it to pick it up automatically).Īlso the image needs some cleanups like removing apt cache etc. And maybe I missed some docker command settings for all possible cases. but could be easy integrated into the docker image as base. The settings.json of the workspace is currently manually created after container is running. The docker file builds the sugar into the code-server image, they have a "mod" for integrating docker into their images, but hard to maintain with custom version etc. Maybe it needs a bit of cleanup und convert to a template but should be almost 1:1 mapping. I'm happy if you would integrate that with your plugin, I assume you would have less effort to bring this up and running and support with more features than self dev a gui. Synatx highlighting and help for compose and docker filesīash completion in the vscode terminal for docker and docker-compose Support for managing/debug docker via vscode docker explorer. I have a working compose file that setups a vscode server container based on linuxservers/code-server with docker, docker compose with same version as you provide in the plugin and some suggar. Why not include just a vscode server container for editing the files. I just prepped a dockerdev container for my unraid compose management as a supplement for your plugin.
0 kommentar(er)
