I have the following Dockerfile:
FROM ubuntu
ENV NPM_CONFIG_LOGLEVEL warn
ENV admin_user="PeerAdmin" network_name=$1 version=$2 hversion=hlfv1 fabrik_path=/fabric-tools project_dir=$(pwd)
ENV card_store_dir=$project_dir/.card-store stage_dir=$project_dir/.stage env_dir=$project_dir/env is_ok=1 FABRIC_VERSION=hlfv1
WORKDIR /app
COPY . /app
USER root
# RUN chown -R ubuntu:ubuntu .
WORKDIR /app
RUN apt-get update && \
mkdir "$fabrik_path" && \
cd "$fabrik_path" && \
export FABRIC_VERSION=hlfv1 && \
apt-get -y install apt-transport-https ca-certificates curl software-properties-common && \
apt-get -y install curl && \
apt-get -y install unzip && \
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - && \
apt-get -y install docker.io && \
curl -O https://raw.githubusercontent.com/hyperledger/composer-tools/master/packages/fabric-dev-servers/fabric-dev-servers.zip && \
unzip fabric-dev-servers.zip && \
service docker start && \
./downloadFabric.sh && \
./startFabric.sh
Attempting to execute it, I am receiving an error:
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
Commands like service docker start
or systemctl
do not work.
You can't (*) run Docker inside Docker containers or images. You can't (*) start background services inside a Dockerfile. As you say, commands like systemctl
and service
don't (*) work inside Docker anywhere. And in any case you can't use any host-system resources, including the host's Docker socket, from anywhere in a Dockerfile.
You need to redesign this Dockerfile so that it only installs the software and makes no attempt to start it. Ideally a container would start only a single server, and would run it in the foreground as its CMD; otherwise you might depend on things like supervisord to have multiple servers if you must. If your application heavily relies on being able to start things in Docker, you might find it much easier to install in a virtual machine.
(*) Technically there are ways to do all of these things, but they're all tricky and complicated and have implications (up to potentially giving your container unrestricted root access over the host, and your container startup actively reconfiguring some low-level host details).