This is the multi-page printable view of this section. .
Module: DOCKER
- 1: Usage
- 2: Parameters
- 3: Playbooks
- 4: Metrics
- 5: FAQ
Docker is the most popular containerization platform, providing standardized software delivery capabilities.
Pigsty does not rely on Docker to deploy any of its components; instead, it provides the ability to deploy and install Docker — this is an optional module.
Pigsty offers a series of Docker software/tool/application templates for you to choose from as needed. This allows users to quickly spin up various containerized stateless software templates, adding extra functionality. You can use external, Pigsty-managed highly available database clusters while placing stateless applications inside containers.
When running configure, Pigsty automatically selects suitable upstream repositories and mirror acceleration settings based on region (for example, mainland China network environments), to improve image pull speed and availability.
You can easily configure Registry and Proxy settings to flexibly access different image sources.
1 - Usage
Pigsty has built-in Docker support, which you can use to quickly deploy containerized applications.
Getting Started
Docker is an optional module. In Pigsty, whether Docker is installed is controlled by docker_enabled, which is disabled by default.
The docker-ce upstream repository belongs to the infra module. If you need to explicitly include Docker packages in the offline repository, use repo_extra_packages with the docker package alias (mapped to docker-ce and docker-compose-plugin).
After Docker is downloaded, you need to set the docker_enabled: true flag on the nodes where you want to install Docker, and configure other parameters as needed.
Finally, you can use the docker.yml playbook to install it on the nodes:
Installation
If you want to temporarily install Docker directly from the internet on certain nodes, you can use the following command:
This command will first enable the upstream software sources for the node,infra modules on the target nodes, then install the docker-ce and docker-compose-plugin packages (same package names on EL/Debian).
If you want Docker-related packages to be automatically downloaded during Pigsty initialization, refer to the instructions below.
Removal
Because it’s so simple, Pigsty doesn’t provide an uninstall playbook for the Docker module. You can directly remove Docker using an Ansible command:
Download
To download Docker during Pigsty installation, confirm that repo_modules includes infra (the module containing Docker upstream repositories),
then specify Docker packages in repo_packages or repo_extra_packages.
The docker specified here (which actually corresponds to the docker-ce and docker-compose-plugin packages) will be automatically downloaded to the local repository during the default deploy.yml process.
After downloading, the Docker packages will be available to all nodes via the local repository.
If you’ve already completed Pigsty installation and the local repository is initialized, you can run ./infra.yml -t repo_build after modifying the configuration to re-download and rebuild the offline repository.
Installing Docker requires the Docker YUM/APT repository. In the v4.x default repo_upstream, this repository belongs to the infra module and is usually available out of the box.
Repository
Downloading Docker requires upstream internet software repositories, which are defined in the default repo_upstream with module name infra:
You can reference this repository using the infra module name in repo_modules and node_repo_modules.
Docker’s official software repository is blocked by default in mainland China. Use a mainland mirror to complete the download.
If you’re in mainland China and encounter Docker download failures, check whether region is set to default in your configuration inventory. The automatically configured region: china can resolve this issue.
Proxy
If your network environment requires a proxy server to access the internet, you can configure the proxy_env parameter in Pigsty’s configuration inventory. This parameter will be written to the proxy related configuration in Docker’s configuration file.
When running configure with the -x parameter, the proxy server configuration from your current environment will be automatically generated into Pigsty’s configuration file under proxy_env.
In addition to using a proxy server, you can also configure Docker Registry Mirrors to bypass blocks.
Registry Mirrors
You can use the docker_registry_mirrors parameter to specify Docker Registry Mirrors:
For users outside the firewall, in addition to the official DockerHub site, you can also consider using the quay.io mirror site. If your internal network environment already has mature image infrastructure, you can use your internal Docker registry mirrors to avoid being affected by external mirror sites and improve download speeds.
Users of public cloud providers can consider using free internal Docker mirrors. For example, if you’re using Alibaba Cloud, you can use Alibaba Cloud’s internal Docker mirror site (requires login):
If you’re using Tencent Cloud, you can use Tencent Cloud’s internal Docker mirror site (requires internal network):
Additionally, you can use CF-Workers-docker.io to quickly set up your own Docker image proxy. You can also consider using free Docker proxy mirrors (use at your own risk!)
Pulling Images
The docker_image and docker_image_cache parameters can be used to directly specify a list of images to pull during Docker installation.
Using this feature, Docker will come with the specified images after installation (provided they can be successfully pulled; this task will be automatically ignored and skipped on failure).
For example, you can specify images to pull in the configuration inventory:
Another way to preload images is to use locally save d tgz archives: if you’ve previously exported Docker images using docker save xxx | gzip -c > /tmp/docker/xxx.tgz.
These exported image files can be automatically loaded via the glob specified by the docker_image_cache parameter. The default location is: /tmp/docker/*.tgz.
This means you can place images in the /tmp/docker directory beforehand, and after running docker.yml to install Docker, these image packages will be automatically loaded.
For example, in the self-hosted Supabase tutorial, this technique is used. Before spinning up Supabase and installing Docker, the *.tgz image archives from the local /tmp/supabase directory are copied to the target node’s /tmp/docker directory.
Applications
Pigsty provides a series of ready-to-use, Docker Compose-based software templates, which you can use to spin up business software that uses external Pigsty-managed database clusters.
2 - Parameters
The DOCKER module provides 8 configuration parameters.
Parameter Overview
The DOCKER parameter group is used for Docker container engine deployment and configuration, including enable switch, data directory, storage driver, registry mirrors, and monitoring.
| Parameter | Type | Level | Description |
|---|---|---|---|
docker_enabled |
bool |
G/C/I |
Enable Docker on current node? disabled by default |
docker_data |
path |
G/C/I |
Docker data directory, /data/docker by default |
docker_storage_driver |
enum |
G/C/I |
Docker storage driver, overlay2 by default |
docker_cgroups_driver |
enum |
G/C/I |
Docker cgroup driver: cgroupfs or systemd |
docker_registry_mirrors |
string[] |
G/C/I |
Docker registry mirror list |
docker_exporter_port |
port |
G |
Docker metrics exporter port, 9323 by default |
docker_image |
string[] |
G/C/I |
Docker images to pull, empty list by default |
docker_image_cache |
path |
G/C/I |
Docker image cache tarball path, /tmp/docker/*.tgz |
You can use the docker.yml playbook to install and enable Docker on nodes.
Default parameters are defined in roles/docker/defaults/main.yml
docker_enabled
Parameter: docker_enabled, Type: bool, Level: G/C/I
Enable Docker on current node? Default: false, meaning Docker is not enabled.
docker_data
Parameter: docker_data, Type: path, Level: G/C/I
Docker data directory, default is /data/docker.
This directory stores Docker images, containers, volumes, and other data. If you have a dedicated data disk, it’s recommended to point this directory to that disk’s mount point.
docker_storage_driver
Parameter: docker_storage_driver, Type: enum, Level: G/C/I
Docker storage driver, default is overlay2.
See official documentation: https://docs.docker.com/engine/storage/drivers/select-storage-driver/
Available storage drivers include:
overlay2: Recommended default driver, suitable for most scenariosfuse-overlayfs: For rootless container scenariosbtrfs: When using Btrfs filesystemzfs: When using ZFS filesystemvfs: For testing purposes, not recommended for production
docker_cgroups_driver
Parameter: docker_cgroups_driver, Type: enum, Level: G/C/I
Docker cgroup filesystem driver, can be cgroupfs or systemd, default: systemd
docker_registry_mirrors
Parameter: docker_registry_mirrors, Type: string[], Level: G/C/I
Docker registry mirror list, default: [] empty array.
You can use Docker mirror sites to accelerate image pulls. Here are some examples:
You can also consider using a Cloudflare Worker to set up a Docker Proxy for faster access.
If pull speeds are still too slow, consider using alternative registries: docker login quay.io
docker_exporter_port
Parameter: docker_exporter_port, Type: port, Level: G
Docker metrics exporter port, default is 9323.
The Docker daemon exposes Prometheus-format monitoring metrics on this port for collection by monitoring infrastructure.
docker_image
Parameter: docker_image, Type: string[], Level: G/C/I
List of Docker images to pull, default is empty list [].
Docker image names specified here will be automatically pulled during the installation phase.
docker_image_cache
Parameter: docker_image_cache, Type: path, Level: G/C/I
Local Docker image cache tarball glob pattern, default is /tmp/docker/*.tgz.
You can use docker save | gzip to package images and automatically import them during Docker installation via this parameter.
.tgz tarball files matching this pattern will be imported into Docker one by one using:
3 - Playbooks
The Docker module provides a default playbook docker.yml for installing Docker Daemon and Docker Compose.
docker.yml
Playbook source file: docker.yml
Running this playbook will install docker-ce and docker-compose-plugin on target nodes with the docker_enabled: true flag, and enable the dockerd service.
The following are the available task subsets in the docker.yml playbook:
docker_install: Install Docker and Docker Compose packages on the nodedocker_admin: Add specified users to the Docker admin user groupdocker_dir: Create Docker related directoriesdocker_config: Generate Docker daemon service configuration filedocker_launch: Start the Docker daemon servicedocker_register: Register Docker daemon as a monitoring target (alias tags:register/add_metrics)docker_image: Attempt to load pre-cached image tarballs from/tmp/docker/*.tgz(if they exist)
The Docker module does not provide a dedicated uninstall playbook. If you need to uninstall Docker, you can manually stop Docker and then remove it:
Changing docker_enabled to false only makes docker.yml skip the entire Docker role. It does not stop or uninstall an existing Docker deployment, nor delete /data/docker.
The manual commands above also leave the data directory in place. Docker’s VictoriaMetrics file-discovery target can be deregistered together with the node through the node_deregister task in node-rm.yml.
4 - Metrics
This snapshot records 123 monitoring metric families for the DOCKER module. The metrics present at runtime vary with package version, enabled collectors, and target state.
| Metric Name | Type | Labels | Description |
|---|---|---|---|
| builder_builds_failed_total | counter | ip, cls, reason, ins, job, instance |
Number of failed image builds |
| builder_builds_triggered_total | counter | ip, cls, ins, job, instance |
Number of triggered image builds |
| docker_up | Unknown | ip, cls, ins, job, instance |
N/A |
| engine_daemon_container_actions_seconds_bucket | Unknown | ip, cls, ins, job, instance, le, action |
N/A |
| engine_daemon_container_actions_seconds_count | Unknown | ip, cls, ins, job, instance, action |
N/A |
| engine_daemon_container_actions_seconds_sum | Unknown | ip, cls, ins, job, instance, action |
N/A |
| engine_daemon_container_states_containers | gauge | ip, cls, ins, job, instance, state |
The count of containers in various states |
| engine_daemon_engine_cpus_cpus | gauge | ip, cls, ins, job, instance |
The number of cpus that the host system of the engine has |
| engine_daemon_engine_info | gauge | ip, cls, architecture, ins, job, instance, os_version, kernel, version, graphdriver, os, daemon_id, commit, os_type |
The information related to the engine and the OS it is running on |
| engine_daemon_engine_memory_bytes | gauge | ip, cls, ins, job, instance |
The number of bytes of memory that the host system of the engine has |
| engine_daemon_events_subscribers_total | gauge | ip, cls, ins, job, instance |
The number of current subscribers to events |
| engine_daemon_events_total | counter | ip, cls, ins, job, instance |
The number of events logged |
| engine_daemon_health_checks_failed_total | counter | ip, cls, ins, job, instance |
The total number of failed health checks |
| engine_daemon_health_check_start_duration_seconds_bucket | Unknown | ip, cls, ins, job, instance, le |
N/A |
| engine_daemon_health_check_start_duration_seconds_count | Unknown | ip, cls, ins, job, instance |
N/A |
| engine_daemon_health_check_start_duration_seconds_sum | Unknown | ip, cls, ins, job, instance |
N/A |
| engine_daemon_health_checks_total | counter | ip, cls, ins, job, instance |
The total number of health checks |
| engine_daemon_host_info_functions_seconds_bucket | Unknown | ip, cls, ins, job, instance, le, function |
N/A |
| engine_daemon_host_info_functions_seconds_count | Unknown | ip, cls, ins, job, instance, function |
N/A |
| engine_daemon_host_info_functions_seconds_sum | Unknown | ip, cls, ins, job, instance, function |
N/A |
| engine_daemon_image_actions_seconds_bucket | Unknown | ip, cls, ins, job, instance, le, action |
N/A |
| engine_daemon_image_actions_seconds_count | Unknown | ip, cls, ins, job, instance, action |
N/A |
| engine_daemon_image_actions_seconds_sum | Unknown | ip, cls, ins, job, instance, action |
N/A |
| engine_daemon_network_actions_seconds_bucket | Unknown | ip, cls, ins, job, instance, le, action |
N/A |
| engine_daemon_network_actions_seconds_count | Unknown | ip, cls, ins, job, instance, action |
N/A |
| engine_daemon_network_actions_seconds_sum | Unknown | ip, cls, ins, job, instance, action |
N/A |
| etcd_debugging_snap_save_marshalling_duration_seconds_bucket | Unknown | ip, cls, ins, job, instance, le |
N/A |
| etcd_debugging_snap_save_marshalling_duration_seconds_count | Unknown | ip, cls, ins, job, instance |
N/A |
| etcd_debugging_snap_save_marshalling_duration_seconds_sum | Unknown | ip, cls, ins, job, instance |
N/A |
| etcd_debugging_snap_save_total_duration_seconds_bucket | Unknown | ip, cls, ins, job, instance, le |
N/A |
| etcd_debugging_snap_save_total_duration_seconds_count | Unknown | ip, cls, ins, job, instance |
N/A |
| etcd_debugging_snap_save_total_duration_seconds_sum | Unknown | ip, cls, ins, job, instance |
N/A |
| etcd_disk_wal_fsync_duration_seconds_bucket | Unknown | ip, cls, ins, job, instance, le |
N/A |
| etcd_disk_wal_fsync_duration_seconds_count | Unknown | ip, cls, ins, job, instance |
N/A |
| etcd_disk_wal_fsync_duration_seconds_sum | Unknown | ip, cls, ins, job, instance |
N/A |
| etcd_disk_wal_write_bytes_total | gauge | ip, cls, ins, job, instance |
Total number of bytes written in WAL. |
| etcd_snap_db_fsync_duration_seconds_bucket | Unknown | ip, cls, ins, job, instance, le |
N/A |
| etcd_snap_db_fsync_duration_seconds_count | Unknown | ip, cls, ins, job, instance |
N/A |
| etcd_snap_db_fsync_duration_seconds_sum | Unknown | ip, cls, ins, job, instance |
N/A |
| etcd_snap_db_save_total_duration_seconds_bucket | Unknown | ip, cls, ins, job, instance, le |
N/A |
| etcd_snap_db_save_total_duration_seconds_count | Unknown | ip, cls, ins, job, instance |
N/A |
| etcd_snap_db_save_total_duration_seconds_sum | Unknown | ip, cls, ins, job, instance |
N/A |
| etcd_snap_fsync_duration_seconds_bucket | Unknown | ip, cls, ins, job, instance, le |
N/A |
| etcd_snap_fsync_duration_seconds_count | Unknown | ip, cls, ins, job, instance |
N/A |
| etcd_snap_fsync_duration_seconds_sum | Unknown | ip, cls, ins, job, instance |
N/A |
| go_gc_duration_seconds | summary | ip, cls, ins, job, instance, quantile |
A summary of the pause duration of garbage collection cycles. |
| go_gc_duration_seconds_count | Unknown | ip, cls, ins, job, instance |
N/A |
| go_gc_duration_seconds_sum | Unknown | ip, cls, ins, job, instance |
N/A |
| go_goroutines | gauge | ip, cls, ins, job, instance |
Number of goroutines that currently exist. |
| go_info | gauge | ip, cls, ins, job, version, instance |
Information about the Go environment. |
| go_memstats_alloc_bytes | counter | ip, cls, ins, job, instance |
Total number of bytes allocated, even if freed. |
| go_memstats_alloc_bytes_total | counter | ip, cls, ins, job, instance |
Total number of bytes allocated, even if freed. |
| go_memstats_buck_hash_sys_bytes | gauge | ip, cls, ins, job, instance |
Number of bytes used by the profiling bucket hash table. |
| go_memstats_frees_total | counter | ip, cls, ins, job, instance |
Total number of frees. |
| go_memstats_gc_sys_bytes | gauge | ip, cls, ins, job, instance |
Number of bytes used for garbage collection system metadata. |
| go_memstats_heap_alloc_bytes | gauge | ip, cls, ins, job, instance |
Number of heap bytes allocated and still in use. |
| go_memstats_heap_idle_bytes | gauge | ip, cls, ins, job, instance |
Number of heap bytes waiting to be used. |
| go_memstats_heap_inuse_bytes | gauge | ip, cls, ins, job, instance |
Number of heap bytes that are in use. |
| go_memstats_heap_objects | gauge | ip, cls, ins, job, instance |
Number of allocated objects. |
| go_memstats_heap_released_bytes | gauge | ip, cls, ins, job, instance |
Number of heap bytes released to OS. |
| go_memstats_heap_sys_bytes | gauge | ip, cls, ins, job, instance |
Number of heap bytes obtained from system. |
| go_memstats_last_gc_time_seconds | gauge | ip, cls, ins, job, instance |
Number of seconds since 1970 of last garbage collection. |
| go_memstats_lookups_total | counter | ip, cls, ins, job, instance |
Total number of pointer lookups. |
| go_memstats_mallocs_total | counter | ip, cls, ins, job, instance |
Total number of mallocs. |
| go_memstats_mcache_inuse_bytes | gauge | ip, cls, ins, job, instance |
Number of bytes in use by mcache structures. |
| go_memstats_mcache_sys_bytes | gauge | ip, cls, ins, job, instance |
Number of bytes used for mcache structures obtained from system. |
| go_memstats_mspan_inuse_bytes | gauge | ip, cls, ins, job, instance |
Number of bytes in use by mspan structures. |
| go_memstats_mspan_sys_bytes | gauge | ip, cls, ins, job, instance |
Number of bytes used for mspan structures obtained from system. |
| go_memstats_next_gc_bytes | gauge | ip, cls, ins, job, instance |
Number of heap bytes when next garbage collection will take place. |
| go_memstats_other_sys_bytes | gauge | ip, cls, ins, job, instance |
Number of bytes used for other system allocations. |
| go_memstats_stack_inuse_bytes | gauge | ip, cls, ins, job, instance |
Number of bytes in use by the stack allocator. |
| go_memstats_stack_sys_bytes | gauge | ip, cls, ins, job, instance |
Number of bytes obtained from system for stack allocator. |
| go_memstats_sys_bytes | gauge | ip, cls, ins, job, instance |
Number of bytes obtained from system. |
| go_threads | gauge | ip, cls, ins, job, instance |
Number of OS threads created. |
| logger_log_entries_size_greater_than_buffer_total | counter | ip, cls, ins, job, instance |
Number of log entries which are larger than the log buffer |
| logger_log_read_operations_failed_total | counter | ip, cls, ins, job, instance |
Number of log reads from container stdio that failed |
| logger_log_write_operations_failed_total | counter | ip, cls, ins, job, instance |
Number of log write operations that failed |
| process_cpu_seconds_total | counter | ip, cls, ins, job, instance |
Total user and system CPU time spent in seconds. |
| process_max_fds | gauge | ip, cls, ins, job, instance |
Maximum number of open file descriptors. |
| process_open_fds | gauge | ip, cls, ins, job, instance |
Number of open file descriptors. |
| process_resident_memory_bytes | gauge | ip, cls, ins, job, instance |
Resident memory size in bytes. |
| process_start_time_seconds | gauge | ip, cls, ins, job, instance |
Start time of the process since unix epoch in seconds. |
| process_virtual_memory_bytes | gauge | ip, cls, ins, job, instance |
Virtual memory size in bytes. |
| process_virtual_memory_max_bytes | gauge | ip, cls, ins, job, instance |
Maximum amount of virtual memory available in bytes. |
| promhttp_metric_handler_requests_in_flight | gauge | ip, cls, ins, job, instance |
Current number of scrapes being served. |
| promhttp_metric_handler_requests_total | counter | ip, cls, ins, job, instance, code |
Total number of scrapes by HTTP status code. |
| scrape_duration_seconds | Unknown | ip, cls, ins, job, instance |
N/A |
| scrape_samples_post_metric_relabeling | Unknown | ip, cls, ins, job, instance |
N/A |
| scrape_samples_scraped | Unknown | ip, cls, ins, job, instance |
N/A |
| scrape_series_added | Unknown | ip, cls, ins, job, instance |
N/A |
| swarm_dispatcher_scheduling_delay_seconds_bucket | Unknown | ip, cls, ins, job, instance, le |
N/A |
| swarm_dispatcher_scheduling_delay_seconds_count | Unknown | ip, cls, ins, job, instance |
N/A |
| swarm_dispatcher_scheduling_delay_seconds_sum | Unknown | ip, cls, ins, job, instance |
N/A |
| swarm_manager_configs_total | gauge | ip, cls, ins, job, instance |
The number of configs in the cluster object store |
| swarm_manager_leader | gauge | ip, cls, ins, job, instance |
Indicates if this manager node is a leader |
| swarm_manager_networks_total | gauge | ip, cls, ins, job, instance |
The number of networks in the cluster object store |
| swarm_manager_nodes | gauge | ip, cls, ins, job, instance, state |
The number of nodes |
| swarm_manager_secrets_total | gauge | ip, cls, ins, job, instance |
The number of secrets in the cluster object store |
| swarm_manager_services_total | gauge | ip, cls, ins, job, instance |
The number of services in the cluster object store |
| swarm_manager_tasks_total | gauge | ip, cls, ins, job, instance, state |
The number of tasks in the cluster object store |
| swarm_node_manager | gauge | ip, cls, ins, job, instance |
Whether this node is a manager or not |
| swarm_raft_snapshot_latency_seconds_bucket | Unknown | ip, cls, ins, job, instance, le |
N/A |
| swarm_raft_snapshot_latency_seconds_count | Unknown | ip, cls, ins, job, instance |
N/A |
| swarm_raft_snapshot_latency_seconds_sum | Unknown | ip, cls, ins, job, instance |
N/A |
| swarm_raft_transaction_latency_seconds_bucket | Unknown | ip, cls, ins, job, instance, le |
N/A |
| swarm_raft_transaction_latency_seconds_count | Unknown | ip, cls, ins, job, instance |
N/A |
| swarm_raft_transaction_latency_seconds_sum | Unknown | ip, cls, ins, job, instance |
N/A |
| swarm_store_batch_latency_seconds_bucket | Unknown | ip, cls, ins, job, instance, le |
N/A |
| swarm_store_batch_latency_seconds_count | Unknown | ip, cls, ins, job, instance |
N/A |
| swarm_store_batch_latency_seconds_sum | Unknown | ip, cls, ins, job, instance |
N/A |
| swarm_store_lookup_latency_seconds_bucket | Unknown | ip, cls, ins, job, instance, le |
N/A |
| swarm_store_lookup_latency_seconds_count | Unknown | ip, cls, ins, job, instance |
N/A |
| swarm_store_lookup_latency_seconds_sum | Unknown | ip, cls, ins, job, instance |
N/A |
| swarm_store_memory_store_lock_duration_seconds_bucket | Unknown | ip, cls, ins, job, instance, le |
N/A |
| swarm_store_memory_store_lock_duration_seconds_count | Unknown | ip, cls, ins, job, instance |
N/A |
| swarm_store_memory_store_lock_duration_seconds_sum | Unknown | ip, cls, ins, job, instance |
N/A |
| swarm_store_read_tx_latency_seconds_bucket | Unknown | ip, cls, ins, job, instance, le |
N/A |
| swarm_store_read_tx_latency_seconds_count | Unknown | ip, cls, ins, job, instance |
N/A |
| swarm_store_read_tx_latency_seconds_sum | Unknown | ip, cls, ins, job, instance |
N/A |
| swarm_store_write_tx_latency_seconds_bucket | Unknown | ip, cls, ins, job, instance, le |
N/A |
| swarm_store_write_tx_latency_seconds_count | Unknown | ip, cls, ins, job, instance |
N/A |
| swarm_store_write_tx_latency_seconds_sum | Unknown | ip, cls, ins, job, instance |
N/A |
| up | Unknown | ip, cls, ins, job, instance |
N/A |
5 - FAQ
Who Can Run Docker Commands?
By default, Pigsty adds both the management user running the playbook on the remote node (i.e., the SSH login user on the target node) and the admin user specified in the node_admin_username parameter to the Docker operating system group.
All users in this group (docker) can manage Docker using the docker CLI command.
If you want other users to be able to run Docker commands, add that OS user to the docker group:
Working Through a Proxy
During Docker installation, if the proxy_env parameter exists,
the HTTP proxy server configuration will be written to the /etc/docker/daemon.json configuration file.
Docker will use this proxy server when pulling images from upstream registries.
Tip: Running configure with the -x flag will write the proxy server configuration from your current environment into proxy_env.
Using Mirror Registries
If DockerHub access is slow in mainland China network environments, you can prioritize:
- Configure available mirrors with
docker_registry_mirrors - Or configure
proxy_envto pull via proxy - Or directly use other public registries (such as
quay.io)
For example:
Adding Docker to Monitoring
During Docker module installation, you can register Docker as a monitoring target by running the docker_register subtask (or alias tag add_metrics) for specific nodes:
Using Software Templates
Pigsty provides a collection of software templates that can be launched using Docker Compose, ready to use out of the box.
But you need to install the Docker module first.