Docker: Getting Started

How to get started with Stackhero for Docker

👋 Welcome to the Stackhero documentation!

Stackhero offers a ready-to-use Docker cloud CaaS (Containers as a Service) solution that provides a host of benefits, including:

  • Easily deploy your containers to production with just a docker-compose up.
  • Customizable domain name secured with HTTPS (for example, https://api.your-company.com, https://www.your-company.com, https://backoffice.your-company.com).
  • Optimal performance and robust security powered by a private and dedicated VM.
  • Effortless updates with just a click.

Save time and simplify your life: it only takes 5 minutes to try Stackhero's Docker CaaS cloud hosting solution and deploy your containers to production!

Docker CLI should be installed on your computer. If you haven't installed it yet, you can download it here: https://www.docker.com/products/docker-desktop/.

With Stackhero for Docker, you can connect to your Docker server remotely from your computer just as you would when working locally. This setup allows you to maintain your usual workflow while providing a robust way to manage your containers in production.

To achieve this, Docker "contexts" are utilized. Docker contexts enable you to use the Docker CLI on your computer and specify where the commands should execute: on your local Docker daemon (as usual) or on your Stackhero for Docker instance.

To connect remotely to your Stackhero for Docker instance, you will first need to install its certificates. These certificates ensure secure authentication and encryption between your computer and your Stackhero for Docker instance.

On your computer, you can use the following command:

# HOST is your Stackhero for Docker instance domain name (<XXXXXX>.stackhero-network.com).
# SERVICE_ID is your Stackhero service ID.
# CERTIFICATES_PASSWORD is the password defined in your Stackhero for Docker configuration.
(export HOST="<XXXXXX>.stackhero-network.com"
export SERVICE_ID="<SERVICE_ID>"
export CERTIFICATES_PASSWORD="<CERTIFICATES_PASSWORD>"

cd /tmp/ \
  && curl -o certificates.tar https://docker:$CERTIFICATES_PASSWORD@$HOST/stackhero/docker/certificates.tar \
  && tar -xf certificates.tar \
  && (docker context rm -f $HOST 2> /dev/null || true) \
  && docker context create $HOST \
    --description "$SERVICE_ID ($HOST)" \
    --docker "host=tcp://$HOST:2376,ca=ca.pem,cert=cert.pem,key=key.pem")

You have now created a Docker context that is named after your service domain name. To view all your contexts, you can run the command docker context ls.

If you update your service domain, the certificates will change, and you will need to reinstall them.

Currently, if you list your containers with the command docker ps, your Docker CLI will use your local Docker daemon, displaying containers running on your computer.

For instance, you can run this command to get your Docker daemon public IP: docker run --rm alpine wget -q -O - ifconfig.me. Since the container is running on your computer, you will see your internet router's IP as a reply.

Let us change the Docker context to use your Stackhero for Docker instance. Simply run the command docker context use <XXXXXX>.stackhero-network.com. Now, Docker commands initiated on your computer will execute securely on your remote Docker daemon.

Run the same command again to retrieve your Docker daemon's public IP: docker run --rm alpine wget -q -O - ifconfig.me. You should now see your Stackhero for Docker instance's public IP, confirming that your container is running on your server and not on your computer anymore.

To revert to using your local Docker daemon, simply switch back your Docker context to "default": docker context use default.

When you mount a volume on a remote container, the data accessible will be the ones on the remote server and not those on your computer. Thus, running a command like docker run -it -v ${PWD}:/mnt alpine will not mount the directory from your computer as you might expect.

Like the Docker CLI, the Docker-compose CLI will use your current context. Therefore, once you have switched to your remote instance with docker context use <XXXXXX>.stackhero-network.com, every Docker-compose command will execute on your remote instance as well.

Using the docker context command is effective, but it might not be the best approach when handling contexts in your scripts or Makefiles. In such cases, consider using the DOCKER_CONTEXT environment variable, which is detailed in our advanced documentation pages.