Docker consulting and support in Pittsburgh and Cleveland

Containerizing an application

Before containerizing an application we find out what it reads, what it writes, which ports it uses, and what it needs at startup. Code and runtime are disposable. Databases and uploaded files must persist, so they go into named volumes or bind mounts, never inside the container.

Secrets such as database passwords stay out of images and version control. They are supplied to the container when it starts.

Docker Compose for business applications

For one host, Docker Compose is often the right tool. A single file defines the application, its database, and its cache, and you start everything with one command.

• Reverse proxy and TLS: a proxy terminates HTTPS, routes by hostname, and renews certificates, so applications are not exposed directly.
• Restart behavior: restart policies and health checks bring services back after a crash or a reboot.
• Monitoring: uptime checks and logs feed the same dashboards as your other systems.

Image registries and CI builds

Building images on a laptop and copying them to a server does not scale past one person. We set up a private registry and a GitLab CI pipeline that builds an image whenever the code changes, tags it with a version, and publishes it. Deployments then pull a known, tagged image, and rolling back means pointing to the previous tag.

Backups and security updates

Containers are disposable, but their volumes are not. We back up volumes and databases on a schedule, send copies offsite, and run test restores. For database containers we use the database's own dump or backup method instead of copying files from a running service. See our backup and disaster recovery services.

Security updates come in two layers. The host operating system needs patching, and the images need rebuilding when their base image or a library is fixed. We schedule both, test the result, and keep the previous version available. Docker hosts often run as virtual machines on Proxmox.

When to move to Kubernetes

Docker Compose runs on one host. Consider Kubernetes when losing that host is no longer acceptable, or when you need services spread across several machines, updated without downtime and restarted elsewhere when a machine fails. A cluster takes more work to operate, so we recommend it only when you need those things. At that point we move workloads onto the clusters described in Linux and Kubernetes consulting.

How an engagement works

1. Discovery call. We learn what the application does and where it runs.
2. Written scope. A plan for containers, proxy, backups, and updates.
3. Build and handover. We deploy, test a restore, and document how to operate it.
4. Ongoing support. Optional, with a named engineer.

We reply within one business day. Our offices are in Coraopolis and Beaver Falls, Pennsylvania, and Cleveland-area on-site work is arranged around the project.

Questions about Docker support

Is Docker Compose good enough for production?

For many business applications on a single host, yes, provided you have backups, monitoring, and a patching routine. It does not give you failover across hosts.

Can you containerize software we did not write?

Often, yes. Many applications publish container images, and we configure and back them up. For custom software, we package it or work with your developers.

Can you take over a Docker server someone else set up?

Yes. We inventory the containers, volumes, and certificates, check the backups, and document what we find before changing anything.