March 25, 201511 yr Hey guys sorry drop in on your conversation here. I have successfully for awhile now, been able to turn desktop apps into webapps. Via VNC and novnc and using a frame buffer. My tinyMediaManager container is a perfect example of this. You can find https://github.com/HurricaneHernandez/tmm
March 25, 201511 yr lol, hurricane. i sent jonp a PM this morning about your container, when i reread the blurb at the beginning about novnc i remembered your container.
March 25, 201511 yr Yeah, I thought it was awesome when I first discovered it like 3 months ago. I always wanted a mediamanager that ran on unRAID, but unfortunately most where desktop apps. So when I discovered the framebuffer, novnc, and X11vnc. I was in heaven. If you have any question let me know, and I will be happy to assist.
March 25, 201511 yr Yeah, I thought it was awesome when I first discovered it like 3 months ago. I always wanted a mediamanager that ran on unRAID, but unfortunately most where desktop apps. So when I discovered the framebuffer, novnc, and X11vnc. I was in heaven. If you have any question let me know, and I will be happy to assist. this rdp based container is a lot more responsive though.
March 25, 201511 yr Nice work! Hoping to have some more time after this week to work on this with Eric a bit further. The audio not coming through isn't really a huge issue for us, but it'd be nice to solve later down the road. The #1 interest is for apps like Crashplan that do not have a web-based UI (or Calibre I guess would be the other). Would it be possible to develop a "vanilla" docker app for this, to allow for the end-user to install several apps on if they so desired, I use the current crash plan docker and agree that this would make an excellent alternative but wouldn't want to limit it's possibilities to just a series of single dockers. Maybe like an "easy-VM" although I understand that may be violating several if not all docker best practice guidelines...
March 25, 201511 yr Nice work! Hoping to have some more time after this week to work on this with Eric a bit further. The audio not coming through isn't really a huge issue for us, but it'd be nice to solve later down the road. The #1 interest is for apps like Crashplan that do not have a web-based UI (or Calibre I guess would be the other). Would it be possible to develop a "vanilla" docker app for this, to allow for the end-user to install several apps on if they so desired, I use the current crash plan docker and agree that this would make an excellent alternative but wouldn't want to limit it's possibilities to just a series of single dockers. Maybe like an "easy-VM" although I understand that may be violating several if not all docker best practice guidelines... It'd be tricky cos as is at the moment, soon as the container is updated, you'll lose anything you install.
March 25, 201511 yr Nice work! Hoping to have some more time after this week to work on this with Eric a bit further. The audio not coming through isn't really a huge issue for us, but it'd be nice to solve later down the road. The #1 interest is for apps like Crashplan that do not have a web-based UI (or Calibre I guess would be the other). Would it be possible to develop a "vanilla" docker app for this, to allow for the end-user to install several apps on if they so desired, I use the current crash plan docker and agree that this would make an excellent alternative but wouldn't want to limit it's possibilities to just a series of single dockers. Maybe like an "easy-VM" although I understand that may be violating several if not all docker best practice guidelines... It'd be tricky cos as is at the moment, soon as the container is updated, you'll lose anything you install. Not necessarily, users could always use the docker commit command to make an image of the current running container from which they could then make more containers from. It wouldn't be easy to use, but it's definitely possible.
March 25, 201511 yr Author So maybe we should create a new thread to discuss this, but here's where I'm sitting on this right now: Feel a bit like a boob for not knowing about HH's VNC heaven before yesterday, but that's ok. I'm man enough to admit when I missed a big one. While I feel the growing trend for Linux apps has been to move them to being browser/HTML5 based, there are still some that require a desktop GUI and others that have more/better functionality in their desktop GUI over their web-based version. With things like noVNC and Guacamole, we can make it transparent to the user.When they click an app icon in Docker, the context menu gives them an option for "interface" or "app control" (we'll figure out the exact name later). If it's a webGui app, the option will open a new browser tab/window to the app's web interface If it's a deskGui app, the option will open a new browser tab/window to the app's desktop interface via a remote graphics protocol and an embedded HTML5 client. [*]The challenges are: what protocol to use what client to use how to manage VNC ports between both Docker and Virtual Machines Now to respond to CHBMB's question: Would it be possible to develop a "vanilla" docker app for this, to allow for the end-user to install several apps on if they so desired, I use the current crash plan docker and agree that this would make an excellent alternative but wouldn't want to limit it's possibilities to just a series of single dockers. Maybe like an "easy-VM" although I understand that may be violating several if not all docker best practice guidelines... I'd like to have two base images created for the community to use or at least reference when building their own. We're not going to stop anyone who wants to align to a different base image (Phusion, Arch, etc.). We just want to provide an option to simplify things for container authors and for those that do want to use their own base image, at least provide a Dockerfile as a frame of reference for them. Base image 1: For Applications w/ Web Interfaces Base image 2: For Applications w/ Desktop Interfaces Base image 1 I think is pretty self-explanatory, but base image 2 could be made into a full virtual desktop where all user-created data is stored outside the image through volume mappings, but the OS and it's packages would be updated independently from the user installed components. That could be tricky and in the end, maybe not all that valuable. I'd rather keep each desktop application in it's own separate container and just connect to the application interface itself when I need it. I don't think we need a full Linux virtual desktop with persistent storage really. That would be a pretty niche use case. The benefit of keeping the OS and App layer's attached is to keep upgrades in alignment. Let's say an app update comes out but it relies upon upgrades to other packages in the base image. Now you're in a situation where your images are out of alignment and problems can ensue. If we think about Containers as a virtual image which marries an OS operating environment to a single application, we simplify supportability. I'm definitely interested to hear examples of where a fully persistent virtual desktop through Docker makes sense because if I'm missing something here, I want to know. So I'm interested to hear thoughts on this from everyone and let me know if you guys think I should post this in a new thread instead and I'll split the topic.
March 25, 201511 yr So maybe we should create a new thread to discuss this, but here's where I'm sitting on this right now: Feel a bit like a boob for not knowing about HH's VNC heaven before yesterday, but that's ok. I'm man enough to admit when I missed a big one. While I feel the growing trend for Linux apps has been to move them to being browser/HTML5 based, there are still some that require a desktop GUI and others that have more/better functionality in their desktop GUI over their web-based version. With things like noVNC and Guacamole, we can make it transparent to the user.When they click an app icon in Docker, the context menu gives them an option for "interface" or "app control" (we'll figure out the exact name later). If it's a webGui app, the option will open a new browser tab/window to the app's web interface If it's a deskGui app, the option will open a new browser tab/window to the app's desktop interface via a remote graphics protocol and an embedded HTML5 client. [*]The challenges are: what protocol to use what client to use how to manage VNC ports between both Docker and Virtual Machines Now to respond to CHBMB's question: Would it be possible to develop a "vanilla" docker app for this, to allow for the end-user to install several apps on if they so desired, I use the current crash plan docker and agree that this would make an excellent alternative but wouldn't want to limit it's possibilities to just a series of single dockers. Maybe like an "easy-VM" although I understand that may be violating several if not all docker best practice guidelines... I'd like to have two base images created for the community to use or at least reference when building their own. We're not going to stop anyone who wants to align to a different base image (Phusion, Arch, etc.). We just want to provide an option to simplify things for container authors and for those that do want to use their own base image, at least provide a Dockerfile as a frame of reference for them. Base image 1: For Applications w/ Web Interfaces Base image 2: For Applications w/ Desktop Interfaces Base image 1 I think is pretty self-explanatory, but base image 2 could be made into a full virtual desktop where all user-created data is stored outside the image through volume mappings, but the OS and it's packages would be updated independently from the user installed components. That could be tricky and in the end, maybe not all that valuable. I'd rather keep each desktop application in it's own separate container and just connect to the application interface itself when I need it. I don't think we need a full Linux virtual desktop with persistent storage really. That would be a pretty niche use case. The benefit of keeping the OS and App layer's attached is to keep upgrades in alignment. Let's say an app update comes out but it relies upon upgrades to other packages in the base image. Now you're in a situation where your images are out of alignment and problems can ensue. If we think about Containers as a virtual image which marries an OS operating environment to a single application, we simplify supportability. I'm definitely interested to hear examples of where a fully persistent virtual desktop through Docker makes sense because if I'm missing something here, I want to know. So I'm interested to hear thoughts on this from everyone and let me know if you guys think I should post this in a new thread instead and I'll split the topic. Protocol has to be rdp, I think I found a noVNC like app for rdp. I'm in the process of updating my TMM to xrdp for demonstration purposes. I don't think base image 2 is necessary, but there will always be someone to argue. Base Image 1 makes perfect sense and keeps with the docker philosophy of docker base images being contained applications.
March 25, 201511 yr Author So maybe we should create a new thread to discuss this, but here's where I'm sitting on this right now: Feel a bit like a boob for not knowing about HH's VNC heaven before yesterday, but that's ok. I'm man enough to admit when I missed a big one. While I feel the growing trend for Linux apps has been to move them to being browser/HTML5 based, there are still some that require a desktop GUI and others that have more/better functionality in their desktop GUI over their web-based version. With things like noVNC and Guacamole, we can make it transparent to the user.When they click an app icon in Docker, the context menu gives them an option for "interface" or "app control" (we'll figure out the exact name later). If it's a webGui app, the option will open a new browser tab/window to the app's web interface If it's a deskGui app, the option will open a new browser tab/window to the app's desktop interface via a remote graphics protocol and an embedded HTML5 client. [*]The challenges are: what protocol to use what client to use how to manage VNC ports between both Docker and Virtual Machines Now to respond to CHBMB's question: Would it be possible to develop a "vanilla" docker app for this, to allow for the end-user to install several apps on if they so desired, I use the current crash plan docker and agree that this would make an excellent alternative but wouldn't want to limit it's possibilities to just a series of single dockers. Maybe like an "easy-VM" although I understand that may be violating several if not all docker best practice guidelines... I'd like to have two base images created for the community to use or at least reference when building their own. We're not going to stop anyone who wants to align to a different base image (Phusion, Arch, etc.). We just want to provide an option to simplify things for container authors and for those that do want to use their own base image, at least provide a Dockerfile as a frame of reference for them. Base image 1: For Applications w/ Web Interfaces Base image 2: For Applications w/ Desktop Interfaces Base image 1 I think is pretty self-explanatory, but base image 2 could be made into a full virtual desktop where all user-created data is stored outside the image through volume mappings, but the OS and it's packages would be updated independently from the user installed components. That could be tricky and in the end, maybe not all that valuable. I'd rather keep each desktop application in it's own separate container and just connect to the application interface itself when I need it. I don't think we need a full Linux virtual desktop with persistent storage really. That would be a pretty niche use case. The benefit of keeping the OS and App layer's attached is to keep upgrades in alignment. Let's say an app update comes out but it relies upon upgrades to other packages in the base image. Now you're in a situation where your images are out of alignment and problems can ensue. If we think about Containers as a virtual image which marries an OS operating environment to a single application, we simplify supportability. I'm definitely interested to hear examples of where a fully persistent virtual desktop through Docker makes sense because if I'm missing something here, I want to know. So I'm interested to hear thoughts on this from everyone and let me know if you guys think I should post this in a new thread instead and I'll split the topic. Protocol has to be rdp, I think I found a noVNC like app for rdp. I'm in the process of updating my TMM to xrdp for demonstration purposes. I don't think base image 2 is necessary, but there will always be someone to argue. Base Image 1 makes perfect sense and keeps with the docker philosophy of docker base images being contained applications. Ok, so I'm open to the idea of including support for RDP through HTML5, but Guacamole was ruled out because of it's use of Java. To add guac to unRAID OS would double our bzroot, so that's totally out of the question. How about freerdp or any of the others? I haven't had time to look at their dependency requirements yet.
March 25, 201511 yr Author I don't think base image 2 is necessary, but there will always be someone to argue. Base Image 1 makes perfect sense and keeps with the docker philosophy of docker base images being contained applications. Question on this, why don't you see a difference between 1 and 2? Do you think we should just make one image that includes the desktop gui anyway and if the app needs it, it's there? I guess I'm trying to understand what we should do for apps like Crashplan? Let the app maintainer add their own xvfb / vnc / rdp components?
March 25, 201511 yr So maybe we should create a new thread to discuss this, but here's where I'm sitting on this right now: Feel a bit like a boob for not knowing about HH's VNC heaven before yesterday, but that's ok. I'm man enough to admit when I missed a big one. While I feel the growing trend for Linux apps has been to move them to being browser/HTML5 based, there are still some that require a desktop GUI and others that have more/better functionality in their desktop GUI over their web-based version. With things like noVNC and Guacamole, we can make it transparent to the user.When they click an app icon in Docker, the context menu gives them an option for "interface" or "app control" (we'll figure out the exact name later). If it's a webGui app, the option will open a new browser tab/window to the app's web interface If it's a deskGui app, the option will open a new browser tab/window to the app's desktop interface via a remote graphics protocol and an embedded HTML5 client. [*]The challenges are: what protocol to use what client to use how to manage VNC ports between both Docker and Virtual Machines Now to respond to CHBMB's question: Would it be possible to develop a "vanilla" docker app for this, to allow for the end-user to install several apps on if they so desired, I use the current crash plan docker and agree that this would make an excellent alternative but wouldn't want to limit it's possibilities to just a series of single dockers. Maybe like an "easy-VM" although I understand that may be violating several if not all docker best practice guidelines... I'd like to have two base images created for the community to use or at least reference when building their own. We're not going to stop anyone who wants to align to a different base image (Phusion, Arch, etc.). We just want to provide an option to simplify things for container authors and for those that do want to use their own base image, at least provide a Dockerfile as a frame of reference for them. Base image 1: For Applications w/ Web Interfaces Base image 2: For Applications w/ Desktop Interfaces Base image 1 I think is pretty self-explanatory, but base image 2 could be made into a full virtual desktop where all user-created data is stored outside the image through volume mappings, but the OS and it's packages would be updated independently from the user installed components. That could be tricky and in the end, maybe not all that valuable. I'd rather keep each desktop application in it's own separate container and just connect to the application interface itself when I need it. I don't think we need a full Linux virtual desktop with persistent storage really. That would be a pretty niche use case. The benefit of keeping the OS and App layer's attached is to keep upgrades in alignment. Let's say an app update comes out but it relies upon upgrades to other packages in the base image. Now you're in a situation where your images are out of alignment and problems can ensue. If we think about Containers as a virtual image which marries an OS operating environment to a single application, we simplify supportability. I'm definitely interested to hear examples of where a fully persistent virtual desktop through Docker makes sense because if I'm missing something here, I want to know. So I'm interested to hear thoughts on this from everyone and let me know if you guys think I should post this in a new thread instead and I'll split the topic. Protocol has to be rdp, I think I found a noVNC like app for rdp. I'm in the process of updating my TMM to xrdp for demonstration purposes. I don't think base image 2 is necessary, but there will always be someone to argue. Base Image 1 makes perfect sense and keeps with the docker philosophy of docker base images being contained applications. be nice to auto reconnect to previous session.
March 25, 201511 yr I don't think base image 2 is necessary, but there will always be someone to argue. Base Image 1 makes perfect sense and keeps with the docker philosophy of docker base images being contained applications. Question on this, why don't you see a difference between 1 and 2? Do you think we should just make one image that includes the desktop gui anyway and if the app needs it, it's there? I guess I'm trying to understand what we should do for apps like Crashplan? Let the app maintainer add their own xvfb / vnc / rdp components? NM, I thought baseimage 2 was just a plain desktop that people could do anything with. I thought baseimage 1 was to webify desktop applications.
March 25, 201511 yr FWIW, https://github.com/sparklyballs/private-repo Desktop in there, i replaced the xrdp.ini and you can reconnect to existing sessions from the login by selecting them from the dropdown.
March 25, 201511 yr Nice work! Hoping to have some more time after this week to work on this with Eric a bit further. The audio not coming through isn't really a huge issue for us, but it'd be nice to solve later down the road. The #1 interest is for apps like Crashplan that do not have a web-based UI (or Calibre I guess would be the other). Would it be possible to develop a "vanilla" docker app for this, to allow for the end-user to install several apps on if they so desired, I use the current crash plan docker and agree that this would make an excellent alternative but wouldn't want to limit it's possibilities to just a series of single dockers. Maybe like an "easy-VM" although I understand that may be violating several if not all docker best practice guidelines... I've just re-thought of this in a slightly different manner, setup a basic ubuntu desktop with a few well chosen apps etc.... and have a throwaway workbox. Have a placeholder volume to save out docs etc... and if you mess something up with apt or whatever, just reload the container.
March 25, 201511 yr Author Nice work! Hoping to have some more time after this week to work on this with Eric a bit further. The audio not coming through isn't really a huge issue for us, but it'd be nice to solve later down the road. The #1 interest is for apps like Crashplan that do not have a web-based UI (or Calibre I guess would be the other). Would it be possible to develop a "vanilla" docker app for this, to allow for the end-user to install several apps on if they so desired, I use the current crash plan docker and agree that this would make an excellent alternative but wouldn't want to limit it's possibilities to just a series of single dockers. Maybe like an "easy-VM" although I understand that may be violating several if not all docker best practice guidelines... I've just re-thought of this in a slightly different manner, setup a basic ubuntu desktop with a few well chosen apps etc.... and have a throwaway workbox. Have a placeholder volume to save out docs etc... and if you mess something up with apt or whatever, just reload the container. I would agree that an "app collection" could make sense inside a single docker container (think of openoffice suite). That would be a different use case than server based apps with a desktop GUI. I wouldn't put the Crashplan GUI in the same container as openoffice, but they may share the same base image of Ubuntu:14.04, thus saving space...
March 25, 201511 yr Nice work! Hoping to have some more time after this week to work on this with Eric a bit further. The audio not coming through isn't really a huge issue for us, but it'd be nice to solve later down the road. The #1 interest is for apps like Crashplan that do not have a web-based UI (or Calibre I guess would be the other). Would it be possible to develop a "vanilla" docker app for this, to allow for the end-user to install several apps on if they so desired, I use the current crash plan docker and agree that this would make an excellent alternative but wouldn't want to limit it's possibilities to just a series of single dockers. Maybe like an "easy-VM" although I understand that may be violating several if not all docker best practice guidelines... I've just re-thought of this in a slightly different manner, setup a basic ubuntu desktop with a few well chosen apps etc.... and have a throwaway workbox. Have a placeholder volume to save out docs etc... and if you mess something up with apt or whatever, just reload the container. I would agree that an "app collection" could make sense inside a single docker container (think of openoffice suite). That would be a different use case than server based apps with a desktop GUI. I wouldn't put the Crashplan GUI in the same container as openoffice, but they may share the same base image of Ubuntu:14.04, thus saving space... be unraid "hot desking".....
March 25, 201511 yr a little something and an excuse for me to be heard, lol. I knocked this up, dockerman reported pulling 341 MB from dockerhub for this image.
March 25, 201511 yr Author a little something and an excuse for me to be heard, lol. I knocked this up, dockerman reported pulling 341 MB from dockerhub for this image. Why you knocking on my techno music track? All the cool kids do it! ;-) On a more serious note, that's pretty slick!
March 25, 201511 yr Now to respond to CHBMB's question: I'd like to have two base images created for the community to use or at least reference when building their own. We're not going to stop anyone who wants to align to a different base image (Phusion, Arch, etc.). We just want to provide an option to simplify things for container authors and for those that do want to use their own base image, at least provide a Dockerfile as a frame of reference for them. Base image 1: For Applications w/ Web Interfaces Base image 2: For Applications w/ Desktop Interfaces Base image 1 I think is pretty self-explanatory, but base image 2 could be made into a full virtual desktop where all user-created data is stored outside the image through volume mappings, but the OS and it's packages would be updated independently from the user installed components. That could be tricky and in the end, maybe not all that valuable. I'd rather keep each desktop application in it's own separate container and just connect to the application interface itself when I need it. I don't think we need a full Linux virtual desktop with persistent storage really. That would be a pretty niche use case. The benefit of keeping the OS and App layer's attached is to keep upgrades in alignment. Let's say an app update comes out but it relies upon upgrades to other packages in the base image. Now you're in a situation where your images are out of alignment and problems can ensue. If we think about Containers as a virtual image which marries an OS operating environment to a single application, we simplify supportability. I'm definitely interested to hear examples of where a fully persistent virtual desktop through Docker makes sense because if I'm missing something here, I want to know. So I'm interested to hear thoughts on this from everyone and let me know if you guys think I should post this in a new thread instead and I'll split the topic. Yeah, I can see you're right on this. Perhaps a "easy-vm" isn't the right way to go, still think there is a role for a base-image so users can install any niche apps that there may be no need to create a docker for the community as a whole or for those that are unable to create dockers.
March 25, 201511 yr Just installed CrashPlan on this, and it seems nice. The only caveat is that the container must have "host" network or you have to change the serviceHost variable in /home/ubuntu/crashplan . Maybe it's time to tweak Docker to pass some server variables to containers....\ PS: The install script (needs wget): #!/bin/bash APP_BASENAME=CrashPlan DIR_BASENAME=crashplan TARGETDIR=/usr/local/crashplan BINSDIR=/usr/local/bin MANIFESTDIR=/data INITDIR=/etc/init.d RUNLEVEL=`who -r | sed -e 's/^.*\(run-level [0-9]\).*$/\1/' | cut -d \ -f 2` RUNLVLDIR=/etc/rc${RUNLEVEL}.d JAVACOMMON=`which java` # Downloading Crashplan wget http://download.code42.com/installs/linux/install/CrashPlan/CrashPlan_3.7.0_Linux.tgz -O - | tar -zx -C /tmp # Installation directory cd /tmp/CrashPlan-install INSTALL_DIR=`pwd` # Make the destination dir mkdir -p ${TARGETDIR} # create a file that has our install vars so we can later uninstall echo "" > ${TARGETDIR}/install.vars echo "TARGETDIR=${TARGETDIR}" >> ${TARGETDIR}/install.vars echo "BINSDIR=${BINSDIR}" >> ${TARGETDIR}/install.vars echo "MANIFESTDIR=${MANIFESTDIR}" >> ${TARGETDIR}/install.vars echo "INITDIR=${INITDIR}" >> ${TARGETDIR}/install.vars echo "RUNLVLDIR=${RUNLVLDIR}" >> ${TARGETDIR}/install.vars NOW=`date +%Y%m%d` echo "INSTALLDATE=$NOW" >> ${TARGETDIR}/install.vars cat ${INSTALL_DIR}/install.defaults >> ${TARGETDIR}/install.vars echo "JAVACOMMON=${JAVACOMMON}" >> ${TARGETDIR}/install.vars # Definition of ARCHIVE occurred above when we extracted the JAR we need to evaluate Java environment ARCHIVE=`ls ./*_*.cpi` cd ${TARGETDIR} cat "${INSTALL_DIR}/${ARCHIVE}" | gzip -d -c - | cpio -i --no-preserve-owner cd ${INSTALL_DIR} # the log dir LOGDIR=${TARGETDIR}/log chmod 777 $LOGDIR # Install the control script for the service cp scripts/run.conf ${TARGETDIR}/bin cp scripts/CrashPlanDesktop ${TARGETDIR}/bin/ cat <<'EOT' > /usr/share/applications/CrashPlan.desktop [Desktop Entry] Version=1.0 Encoding=UTF-8 Name=CrashPlan Categories=Utilities; Comment=CrashPlan Desktop Comment[en_CA]=CrashPlan Desktop Exec=/usr/local/crashplan/bin/CrashPlanDesktop Icon=/usr/local/crashplan/skin/icon_app_128x128.png Hidden=false Terminal=false Type=Application GenericName[en_CA]= EOT sed -i -e "s|.*serviceHost.*|serviceHost=172.17.42.1|" ${TARGETDIR}/conf/ui.properties ln -sf ${TARGETDIR}/conf/ui.properties /home/ubuntu/crashplan chmod -R 777 /usr/local/crashplan # Remove install data rm -rf ${INSTALL_DIR} Ok, apparently, Docker will pin it's bridge to 172.17.42.1/24 network unless it's being used by the host for other service (almost impossible to happen). Maybe we can hard code "-bip=172.17.42.1/24" to DOCKER_OPTS and use 172.17.42.1 as host IP on containers. Obs. Changed the script to point serviceHost to 172.17.42.1.
March 25, 201511 yr A new finding: we have to reconfigure the timezone upon startup: if [[ $(cat /etc/timezone) != $TZ ]] ; then echo "$TZ" > /etc/timezone dpkg-reconfigure -f noninteractive tzdata fi
March 25, 201511 yr A new finding: we have to reconfigure the timezone upon startup: if [[ $(cat /etc/timezone) != $TZ ]] ; then echo "$TZ" > /etc/timezone dpkg-reconfigure -f noninteractive tzdata fi being on the prime meridian, this time of year uk time is the same as utc.
March 25, 201511 yr I really like the direction this is heading. I never would have imagined we could have desktop apps on unRAID w/o VMs, this is pretty amazing. Base image 1: For Applications w/ Web Interfaces Base image 2: For Applications w/ Desktop Interfaces Two base container images, with (typically) one app per container sounds perfect. Just installed CrashPlan on this, and it seems nice. We would still have a /config volume for all the stuff that needs to persist, right? (I don't see that in your example, but maybe this was just a proof of concept) That is pretty amazing to think that with a few tweaks to the crashplan docker we'd be able to run the full gui.
Archived
This topic is now archived and is closed to further replies.