I want to know whether if there is any method to remove the ROOT folder within the tomcat /webapps folder after its being deployed by a Docker image.
The reason that I want to achieve this is that I want to run my .war file as the root. I have already renamed my war file as ROOT.war. But when I run my Docker image with the tomcat base image, a ROOT folder is also created by default within the container's tomcat/webapps folder which doesn't allow me to access my ROOT.war file as the root.
My Dockerfile
# Pull base image
FROM tomcat:8.0.30-jre7
# Copy to images tomcat path
COPY /ROOT.war /usr/local/tomcat/webapps/
Sure. You can just delete the already existing ROOT folder as part of your Dockerfile:
# Pull base image
FROM tomcat:8.0.30-jre7
# Delete existing ROOT folder
RUN rm -rf /usr/local/tomcat/webapps/ROOT
# Copy to images tomcat path
COPY ROOT.war /usr/local/tomcat/webapps/
Related
Background
I have a singularity container that was created from a docker image. The docker image has files that are meant to be in the user's home directory (e.g. in $HOME/.files). Because I don't know what the username will be, I put the files in /opt in the container and want to set the user's home to /opt.
I would like to be able to run the container with /opt as the home directory, OR somehow be able to run the container so that the home directory contains the files that already exist within the container
What I have tried:
use the --home flag : This maps a folder on the host as the home directory, rather than a folder in the container.
try overriding the $HOME environment variable with --env HOME=/opt : I get the error Overriding HOME environment variable with SINGULARITYENV_HOME is not permitted
Other questions
this question is related, but interested in mapping the container's home folder to a folder on the host machine
You can use the $HOME shell environment variable when you bind the two directories.
singularity exec -B $HOME:/opt example_container.sif touch /opt/file
Here is the documentation on singularity's bind feature
Fed up with struggling with lib install/dependencies problems, I'm starting working with Singularity.
Though, I'm not sure I understand precisely how it works regarding files management in the sandbox mode (not data, programs).
For example, I designed a very simple definition file that is just a "naked" Debian:
Bootstrap: library
From: debian
%post
apt-get update
I create a sandbox with this to add stuff:
sudo singularity build --sandbox Test/ naked_Debian.def
And I try to install a program. But what I don't understand is that I managed to do it, removed the sandbox directory but I think there are still files that were created during the sandbox life (in /dev, /run, /root, etc.). For example, the program that I cloned from git is now in /root of my local (independently of any container).
From what I understood, everything was in the container and should disappear if I remove the sandbox directory. Otherwise, I'm gonna leave a lot of mess with all the tests? And then I can't port the container from system to another.
If I create any new sandbox directory, the program is already there.
Cheers,
Mathieu
By default, singularity mounts $HOME to the container and uses that path as the working directory for singularity shell / exec. Since you're running the sandbox with sudo, /root is being mounted in and that's where any repos you cloned would end up if you didn't cd to a different directory. /tmp is also automatically mounted in, though that is unlikely to cause an issue since it's just temp files.
You have a few options to avoid files ending up in places you don't expect.
Disable automount of home: singularity shell --no-home ...
The default working directory is now / instead of $HOME and files are created directly in sandbox (as opposed to a mounted in directory)
If you want to get files out of the sandbox, you'll either need to copy to /tmp inside the container, and on the host OS from /tmp to the desired location
Set a different location to use as home: singularity shell --home $PWD ...
This mounts in and uses the current directory as $HOME instead of the user's $HOME on the host OS
Simpler to move files between host OS and container, but still creates files in the host OS
Don't mount system directories at all: singularity shell --contain --workdir /some/dir ...
Directories for /tmp and /var/tmp are created inside /some/dir instead of using /tmp and /var/tmp on the host. $HOME has the same path as the host and is used as the working directory, but it is empty and separate from the host OS
Complete separation from host OS, while still allowing some access between container and OS
Additional details on these options can be found in the documentation.
I have made singulaty image and run that. it works perfectly because when I look at the container using this command:
singularity shell image_name
I can see the output. so the question is that, how can I copy the files from the container into the local directory?
This will get your image's file in the current working directory:
singularity exec <image path or url> cp <file in container> .
By default your home and current working directory are mounted into the image, so you can copy the desired files directly to either of those directories.
I'm using MAMP PRO v3.0.7.2
I want to specify a symlink as the document root for a specific entry in MAMP Pro's host section which points to the latest build of my project, which can change many times a day during development. The problem is when I select this symlink as my document root, MAMP rewrites the path to match whichever directory to symlink is pointing to.
The build script for my project updates that symlink to point to the latest release directory on every rebuild, but MAMP still has that previous release as the document root.
So for example I want the document root to be:
/Users/username/Sites/projectname/live
which is a symlink that currently points to a directory:
/Users/username/Sites/projectname/releases/2014-10-24-17_25_52
MAMP does not respect the symlink path, but instead rewrites it to
/Users/username/Sites/projectname/releases/2014-10-24-17_25_52
So when I rebuild my project later, MAMP is still pointing the document root to the path above, but /live is now pointing to
/Users/username/Sites/projectname/releases/2014-10-24-18_17_48
In the past I have configured Apache manually and it was fine with using the symlink as the document root, and whenever I rebuilt the project the most current build resolved at the URL defined in vhosts without having to edit anything or restart Apache.
I tried manually editing the respective VirtualHost entry MAMP's httpd.conf file in Library/Application Support/appsolute/MAMP PRO/conf/httpd.conf, but whenever the server is restarted it overwrites my changes and rewrites all instances of the path back to whatever directory the /live symlink is currently pointing to.
Is there a way around this so that I can specify a symlink as the document root, and have it always point to that symlink rather than the actual directory that is currently being symlinked to? Otherwise I have to manually change it and restart servers many extra times a day, which gets old pretty fast.
I wanted to deploy a zip file as a local resource in yarn. Hence I did:
packageResource.setResource(packageUrl);
packageResource.setSize(packageFile.length());
packageResource.setTimestamp(packageFile.lastModified());
packageResource.setType(LocalResourceType.ARCHIVE);
packageResource.setVisibility(LocalResourceVisibility.APPLICATION);
If my file name is "abc.zip", Yarn unpacks all the zip contents into a folder called "abc", not the current working directory.
For example, it creates something like:
/grid/5/tmp/yarn-local/usercache/(user)/appcache/application_1394223910537_2533883/container_1394223910537_2533883_01_000002/abc
Can I customize this behavior? How do I get Yarn to unzip a file in the current working directory ,instead of creating a new directory?
The use-case is: if my app has some scripts, it would be useful to have all scripts deployed to current directory, instead of having to change the code to reference them from within the folder that Yarn creates.