I'd say it is an anti-pattern as you lose the portability of Docker. Now you will be relying on the build server's configuration instead of portable base image.
If reducing complexity of the Dockerfile is the goal why not do something like this:
Build the .net core project in Docker (eliminates reliance on the build server).
Run the tests (inside or ...
I am trying to pull the images down locally so I can modify them
Container images are immutable. The correct way to do this is to look for the Dockerfile (if you using docker as the container engine) that corresponds to the image and make the relevant changes, rebuild the image and push it to the container registry.
The container registry will be evident ...
Actually, you can use Fuse (eluded to by the answer above).
S3FS-FUSE: This is a free, open-source FUSE plugin and an easy-to-use
utility which supports major Linux distributions & MacOS. S3FS also
takes care of caching files locally to improve performance. This
plugin simply shows the Amazon S3 bucket as a drive on your system.
my understanding is that I'll probably need to modify the images pulled to do this.
Yes and no. It depends on how your ReplicaSet - specifically the associated Deployment - is configured. You can see the corresponding YAML configuration by doing
kubectl -n yournamespace get deployment yourappdeployment -o yaml
kubectl -n yournamespace describe ...
No you can't.
S3 is an object storage, accessed over HTTP or REST for example. Just as you can't mount an HTTP address as a directory you can't mount a S3 bucket as a directory.
Having said that there are some workarounds that expose S3 as a filesystem - e.g. 's3fs' project. How reliable and stable they are I don't know.
I think the question about Docker security in general was already well answered in other places, for example here: https://stackoverflow.com/questions/40844197/what-is-the-docker-security-risk-of-var-run-docker-sock
In your particular instance, I see the following points:
The tests should run on some testing server, possibly even in a VM that is destroyed/...
If you let docker-compose manage the volumes for you, the volumes names in docker-compose.yml will not be the final ones created/used in docker. docker-compose will prepend the volumes names with the compose project name, which is by default the name of the folder holding the compose file. This is to allow separate projects to use the same names without ...
Without seeing the specific error it looks like the container's runtime process is either crashing or exiting. When a docker container's runtime process exits the container stops.
You can get more information about the specific error by using the docker logs command:
docker logs 92455a993a54
According to the error message
PG::DuplicateTable: ERROR: relation "audit_events" already exists
The DB content (within /var/opt/gitlab) is probably corrupted, the state of the DB doesn't match the recorded state of migration tasks.
As you're mounting /var/opt/gitlab as a volume from the host with --volume /docker/gitlab/data:/var/opt/gitlab:Z, there's ...
The issue is that prereqs-ubuntu.sh uses bash to install the npm. While the RUN directive uses sh to run the commands.
Where is the npm installed
root@2cd4a6af90f4:/app# type npm
npm is /root/.nvm/versions/node/v8.16.0/bin/npm
The PATH for the RUN directive
# echo $PATH
The performance difference between linux containers running on Windows, Linux, or Mac will depend entirely upon how much ram you allocate to the Docker Daemon. The difference should not be noticeable. Additionally, you will be able to take advantage of the Alpine base image (~5 Mb) for small, compact containers.
If you need to run IIS in your container, ...
In case anyone else is running into this issue and can't figure it out, I fixed it by running this command:
gcloud auth activate-service-account --key-file key-file.json
And then ran my docker push command and it pushed through.
I learned that it's not required to set the ingress class to nginx as I did in kubernetes.io/ingress.class: nginx. All annotations prefixed with nginx.ingress.kubernetes.io apply to the default Kubernetes ingress. Setting the timeouts is also not required. The only important annotation is
because the default ...
You don't mention orchestration, are you planning to implement all by your own configuration on top of Ubuntu?
I recommend you that take a look at Kubernetes and StatefulSet workloads
You can use Ubuntu as your host to accomplish your needs, but in my experience, you can only need to ...