{"id":36404,"date":"2026-03-03T12:55:55","date_gmt":"2026-03-03T17:55:55","guid":{"rendered":"https:\/\/www.lpi.org\/articles\/\/"},"modified":"2026-03-10T13:41:51","modified_gmt":"2026-03-10T17:41:51","slug":"devops-tools-introduction-07-container-orchestration","status":"publish","type":"post","link":"https:\/\/www.lpi.org\/it\/blog\/2026\/03\/03\/devops-tools-introduction-07-container-orchestration\/","title":{"rendered":"DevOps Tools Introduction #07: Container Orchestration"},"content":{"rendered":"<p>While <a href=\"https:\/\/www.lpi.org\/blog\/2018\/02\/13\/devops-tools-introduction-06-container-basics\/\">individual Docker containers<\/a> usually run a single program, applications in a microservice architecture are usually composed by combining multiple containers, each contributing a specific set of features that make up the complete application. Coordinating the creation and maintenance of the containers that build an application is the task of container orchestration tools.<\/p>\n<p><a href=\"https:\/\/docs.docker.com\/compose\">Docker Compose<\/a> and <a href=\"https:\/\/podman-desktop.io\/docs\/compose\">Podman Compose<\/a> are two of the most widely adopted tools for defining and running multi-container applications. They allow developers to describe an entire application stack in a single <a href=\"https:\/\/www.redhat.com\/en\/topics\/automation\/what-is-yaml\">YAML file<\/a>, making it easy to spin up complex environments with a single command. Understanding how they work \u2014 and how they differ \u2014 is essential for modern Linux system administration and DevOps practices.<\/p>\n<h3>Docker Compose<\/h3>\n<p>Docker Compose follows a client-server model. The <code>docker compose<\/code> command (or the legacy docker-compose binary) communicates with the Docker daemon running on the host. The daemon is responsible for creating containers, networks, and volumes based on the instructions defined in the Compose file.<br \/>\nDocker Compose organizes resources around a project. By default, the project name is derived from the directory containing the Compose file. All containers, networks, and volumes belonging to the same project share a common naming prefix, making them easy to identify and manage collectively.<\/p>\n<h3>Podman Compose<\/h3>\n<p>Podman Compose takes a fundamentally different approach. Unlike Docker, Podman is daemonless \u2014 it does not rely on a persistent background service. Each container runs as a direct child process of the user invoking the command, meaning containers can be run as non-root users without privilege escalation.<\/p>\n<h3>YAML Compose file<\/h3>\n<p>A Compose file is a YAML document describing the services, networks, and volumes of an application. Since version 3, the format has been unified between Docker Compose and Docker Swarm. While the version key is now optional in the latest specification, declaring it explicitly remains a best practice.<\/p>\n<p>A minimal Compose file follows:<\/p>\n<pre>version: '3.8'\r\n\r\nservices:\r\nweb:\r\nimage: nginx:latest\r\nports:\r\n- \"8080:80\"<\/pre>\n<p>This snippet defines a service named web in a Docker Compose file, bearing the following attributes:<\/p>\n<ul>\n<li><code>services<\/code><br \/>\nThis section lists all the containers that are part of the application. In this simple example, there is only one container, named web.<\/li>\n<li><code>web<\/code><br \/>\nThe name of the service. Docker Compose will use this name as the container\u2019s hostname within the internal network.<\/li>\n<li><code>image: nginx:latest<\/code><br \/>\nThe container will be created from the official Nginx image, using the latest tag.<\/li>\n<li><code>ports<\/code><br \/>\nThis publishes container ports to the host machine.<\/li>\n<li>&#8220;<code>8080:80<\/code>&#8221;<br \/>\nThis string maps port 8080 on the host to port 80 inside the container.<\/li>\n<\/ul>\n<h2>Running an Application<\/h2>\n<p>Instead of launching containers individually, Docker Compose or Podman Compose reads the declarative configuration and automatically creates the required networks, volumes, and service containers in the correct order. This approach ensures consistency, repeatability, and simplified lifecycle management, making it easier to deploy, test, and maintain multi-container applications.<\/p>\n<p>Common Docker Compose commands follow:<\/p>\n<pre># Start all services in detached mode\r\n$ docker compose up -d\r\n\r\n# View running services\r\n$ docker compose ps\r\n\r\n# View logs from all services\r\n$ docker compose logs -f\r\n\r\n# Stop and remove all containers and networks\r\n$ docker compose down<\/pre>\n<h2>What are Services, Networks, and Volumes?<\/h2>\n<p>We\u2019ve been using these terms in this article without defining them. Although they are common computer terms, they have particular meanings for Docker and Podman that I\u2019ll describe here.<\/p>\n<h3>Services<\/h3>\n<p>A <a href=\"https:\/\/docs.docker.com\/reference\/compose-file\/services\/\">service<\/a> defines how a container should run, including which image to use, how it should be configured, what ports it exposes, which volumes it mounts, and which networks it connects to. Each service represents a specific role within the application, such as a web server, database, cache, or backend API. Although a service typically runs a single container instance by default, it can also be scaled to run multiple replicas. Services allow developers to model multi-container applications in a structured, declarative way, ensuring that all components work together as a cohesive system.<\/p>\n<p>A service can use a pre-built image from a repository or build an image from a local Dockerfile.<\/p>\n<h3>Networks<\/h3>\n<p><a href=\"https:\/\/docs.docker.com\/reference\/compose-file\/networks\/\">Networks<\/a> define how services communicate with each other and with the outside world. By default, Compose creates an isolated bridge network where all services can reach one another using their service names as DNS hostnames. Custom networks can be defined to segment traffic, improve security, or control communication boundaries between groups of services. For example, a frontend service may be connected to both a public network and a private backend network, while a database service may only be attached to the private network. This logical separation enhances security and maintains a clean architecture within multi-container applications.<\/p>\n<p>Services can be attached to multiple networks. In the following example, the proxy communicates with both the public internet and the private backend, while the database remains isolated:<\/p>\n<pre>services:\r\nproxy:\r\nimage: nginx\r\nnetworks:\r\n- frontend\r\n- backend\r\ndb:\r\nimage: postgres\r\nnetworks:\r\n- backend<\/pre>\n<h3>Volumes<\/h3>\n<p><a href=\"https:\/\/docs.docker.com\/reference\/compose-file\/volumes\/\">Volumes<\/a> provide persistent storage for containers. Since containers are ephemeral by design, any data stored inside them is lost when they are removed. Volumes solve this problem by storing data outside the container\u2019s writable layer, ensuring that important information\u2014such as database files, logs, or uploaded content\u2014remains intact across restarts and updates. Compose allows you to define named volumes for managed storage or use bind mounts to map specific host directories into containers. By separating application logic from persistent data, volumes support durability, portability, and safer container lifecycle management.<\/p>\n<h2>A Complete Example: Web Application Stack<\/h2>\n<p>The following Compose file demonstrates a production-style stack with NGINX, a Node.js app, and PostgreSQL:<\/p>\n<pre>version: '3.8'\r\n\r\nservices:\r\nproxy:\r\nimage: nginx:1.25-alpine\r\nports:\r\n- \"80:80\"\r\nvolumes:\r\n- .\/nginx\/conf.d:\/etc\/nginx\/conf.d:ro\r\ndepends_on:\r\n- app\r\nnetworks:\r\n- frontend\r\nrestart: unless-stopped\r\n\r\napp:\r\nbuild: .\/app\r\nenvironment:\r\n- NODE_ENV=production\r\n- DATABASE_URL=postgres:\/\/admin:secret@db:5432\/appdb\r\ndepends_on:\r\ndb:\r\ncondition: service_healthy\r\nnetworks:\r\n- frontend\r\n- backend\r\nrestart: unless-stopped\r\n\r\ndb:\r\nimage: postgres:15\r\nenvironment:\r\n- POSTGRES_USER=admin\r\n- POSTGRES_PASSWORD=secret\r\n- POSTGRES_DB=appdb\r\nvolumes:\r\n- db_data:\/var\/lib\/postgresql\/data\r\nhealthcheck:\r\ntest: [\"CMD-SHELL\", \"pg_isready -U admin -d appdb\"]\r\ninterval: 10s\r\ntimeout: 5s\r\nretries: 5\r\nnetworks:\r\n- backend\r\nrestart: unless-stopped\r\n\r\nnetworks:\r\nfrontend:\r\nbackend:\r\ninternal: true\r\n\r\nvolumes:\r\ndb_data:\r\n\r\n<\/pre>\n<p>The <code>proxy<\/code> service uses the lightweight nginx:1.25-alpine image and exposes port 80 on the host, mapping it to port 80 inside the container. This makes the web application accessible externally. It mounts a local directory (.<code>\/nginx\/conf.d<\/code>) into the container\u2019s Nginx configuration directory as read-only (:<code>ro<\/code>), ensuring that custom configuration files are applied securely. The <code>depends_on<\/code> directive ensures that the app service is started before the proxy. It connects only to the frontend network and uses a restart policy of <code>unless-stopped<\/code>, meaning that in case of failure it will automatically restart unless explicitly stopped.<\/p>\n<p>The <code>app<\/code> service is built from a local directory (.<code>\/app<\/code>), indicating that it uses a Dockerfile instead of pulling a prebuilt image. It defines environment variables, including <code>NODE_ENV=production<\/code> and a <code>DATABASE_URL<\/code> pointing to the db service. Notice that the database hostname is db, which works because services on the same network can resolve each other by service name. The <code>depends_on<\/code> configuration includes a condition requiring the database service to be healthy before starting, improving startup reliability. The application connects to both the frontend and backend networks, acting as a bridge between external traffic and the internal database layer.<\/p>\n<p>The db service uses the official <code>postgres:15<\/code> image and defines environment variables to initialize the database user, password, and database name. It mounts a named volume (<code>db_data<\/code>) to <code>\/var\/lib\/postgresql\/data<\/code>, ensuring that database data persists even if the container is recreated. A health check is configured using <code>pg_isready<\/code>, which periodically verifies database availability. The service is connected only to the backend network, isolating it from direct external access. Like the other services, it uses the <code>unless-stopped<\/code> restart policy.<\/p>\n<p>The <code>networks<\/code> section defines two custom networks. The frontend network allows communication between the proxy and the application. The backend network is marked as <code>internal: true<\/code>, meaning it is isolated from external access. This enhances security by preventing direct connections to the database from outside the application.<\/p>\n<p>The <code>volumes<\/code> section defines the named volume <code>db_data<\/code>, which is managed by the container engine. This volume stores persistent database data independently of the container lifecycle, ensuring durability across updates and restarts.<\/p>\n<p>This Compose file demonstrates a clean separation of responsibilities, secure network segmentation, health-aware dependencies, and persistent storage management within a structured, declarative application model.<\/p>\n<h2>Update Running Containers to Newer Images<\/h2>\n<p>One of the key advantages of Docker Compose is the ability to update running services in a controlled and predictable way. Instead of manually stopping containers, pulling new images, and recreating them one by one, Compose manages the entire lifecycle declaratively based on the configuration file.<\/p>\n<p>When a new version of an image becomes available\u2014such as <code>nginx:latest<\/code> or <code>postgres:15<\/code>\u2014the first step is to pull the updated images:<\/p>\n<p><code>$ docker compose pull<\/code><\/p>\n<p>This command downloads the newest versions of the images defined in the Compose file without stopping the running containers.<\/p>\n<p>After pulling the updated images, you can recreate the containers using:<\/p>\n<p><code>$ docker compose up -d<\/code><\/p>\n<p>Compose compares the currently running containers with the updated image definitions. If it detects that an image has changed, it stops the old container and creates a new one using the updated image. This process preserves named volumes and networks, ensuring that persistent data (such as database files) remains intact.<\/p>\n<p>Importantly, Docker Compose replaces containers rather than modifying them in place. This immutable infrastructure approach increases reliability and reduces configuration drift. Because volumes are external to the container filesystem, application data persists even when containers are recreated.<\/p>\n<p>By using Docker Compose to manage updates, teams achieve consistent deployments, simplified rollback strategies (by changing image tags), and safer lifecycle management of multi-container applications.<\/p>\n<p>Mastery of these concepts is a foundational requirement for the DevOps Tools certification and for any Linux administrator responsible for containerized application infrastructure.<br \/>\nAs you continue strengthening your DevOps skills and mastering container orchestration concepts, don\u2019t forget to download your free copy of the official <a href=\"https:\/\/learning.lpi.org\/en\/learning-materials\/701-200\/\">Learning Material for the DevOps Tools Engineer<\/a> certification (701-200). It is an excellent resource to deepen your understanding and align your studies with the exam objectives.<\/p>\n<p style=\"text-align: center;\"><a href=\"https:\/\/www.lpi.org\/blog\/2026\/02\/24\/devops-tools-introduction-06-container-basics\/\">&lt;&lt; Read the previous part of this series<\/a>\u00a0| <a href=\"https:\/\/www.lpi.org\/blog\/2026\/03\/10\/devops-tools-introduction-08-container-infrastructure\/\">Read the next post of this series &gt;&gt;<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<p>While individual Docker containers usually run a single program, applications in a microservice architecture are usually composed by combining multiple containers, each contributing a specific set of features that make up the complete application. Coordinating the creation and maintenance of &#8230; <a href=\"https:\/\/www.lpi.org\/it\/blog\/2026\/03\/03\/devops-tools-introduction-07-container-orchestration\/\" class=\"button-link\">Per saperne di pi\u00f9<\/a><\/p>\n","protected":false},"author":66,"featured_media":36406,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"country":[],"language":[304],"ppma_author":[540,571],"class_list":["post-36404","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-none","language-english"],"acf":[],"yoast_head":"<!-- This site is optimized with the Yoast SEO Premium plugin v27.2 (Yoast SEO v27.3) - https:\/\/yoast.com\/product\/yoast-seo-premium-wordpress\/ -->\n<title>DevOps Tools Introduction #07: Container Orchestration - Linux Professional Institute (LPI)<\/title>\n<meta name=\"description\" content=\"Container orchestration explained: Docker Compose, Podman Compose, and managing multi-container DevOps applications.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.lpi.org\/it\/blog\/2026\/03\/03\/devops-tools-introduction-07-container-orchestration\/\" \/>\n<meta property=\"og:locale\" content=\"it_IT\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"DevOps Tools Introduction #07: Container Orchestration\" \/>\n<meta property=\"og:description\" content=\"Container orchestration explained: Docker Compose, Podman Compose, and managing multi-container DevOps applications.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.lpi.org\/it\/blog\/2026\/03\/03\/devops-tools-introduction-07-container-orchestration\/\" \/>\n<meta property=\"og:site_name\" content=\"Linux Professional Institute (LPI)\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/LPIConnect\" \/>\n<meta property=\"article:published_time\" content=\"2026-03-03T17:55:55+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2026-03-10T17:41:51+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.lpi.org\/wp-content\/uploads\/2026\/03\/article-DevOps-Tools-Engineer-v2-Introduction-02-07.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"1440\" \/>\n\t<meta property=\"og:image:height\" content=\"994\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"author\" content=\"Fabian Thorns, Uir\u00e1 Ribeiro\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@lpiconnect\" \/>\n<meta name=\"twitter:site\" content=\"@lpiconnect\" \/>\n<meta name=\"twitter:label1\" content=\"Scritto da\" \/>\n\t<meta name=\"twitter:data1\" content=\"Fabian Thorns\" \/>\n\t<meta name=\"twitter:label2\" content=\"Tempo di lettura stimato\" \/>\n\t<meta name=\"twitter:data2\" content=\"7 minuti\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/www.lpi.org\\\/it\\\/blog\\\/2026\\\/03\\\/03\\\/devops-tools-introduction-07-container-orchestration\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.lpi.org\\\/it\\\/blog\\\/2026\\\/03\\\/03\\\/devops-tools-introduction-07-container-orchestration\\\/\"},\"author\":{\"name\":\"Fabian Thorns\",\"@id\":\"https:\\\/\\\/www.lpi.org\\\/it\\\/#\\\/schema\\\/person\\\/87a340eca845e18d801667fd11e6937c\"},\"headline\":\"DevOps Tools Introduction #07: Container Orchestration\",\"datePublished\":\"2026-03-03T17:55:55+00:00\",\"dateModified\":\"2026-03-10T17:41:51+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.lpi.org\\\/it\\\/blog\\\/2026\\\/03\\\/03\\\/devops-tools-introduction-07-container-orchestration\\\/\"},\"wordCount\":1503,\"commentCount\":0,\"publisher\":{\"@id\":\"https:\\\/\\\/www.lpi.org\\\/it\\\/#organization\"},\"image\":{\"@id\":\"https:\\\/\\\/www.lpi.org\\\/it\\\/blog\\\/2026\\\/03\\\/03\\\/devops-tools-introduction-07-container-orchestration\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.lpi.org\\\/wp-content\\\/uploads\\\/2026\\\/03\\\/article-DevOps-Tools-Engineer-v2-Introduction-02-07.jpg\",\"articleSection\":[\"- None -\"],\"inLanguage\":\"it-IT\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/www.lpi.org\\\/it\\\/blog\\\/2026\\\/03\\\/03\\\/devops-tools-introduction-07-container-orchestration\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.lpi.org\\\/it\\\/blog\\\/2026\\\/03\\\/03\\\/devops-tools-introduction-07-container-orchestration\\\/\",\"url\":\"https:\\\/\\\/www.lpi.org\\\/it\\\/blog\\\/2026\\\/03\\\/03\\\/devops-tools-introduction-07-container-orchestration\\\/\",\"name\":\"DevOps Tools Introduction #07: Container Orchestration - Linux Professional Institute (LPI)\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.lpi.org\\\/it\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/www.lpi.org\\\/it\\\/blog\\\/2026\\\/03\\\/03\\\/devops-tools-introduction-07-container-orchestration\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/www.lpi.org\\\/it\\\/blog\\\/2026\\\/03\\\/03\\\/devops-tools-introduction-07-container-orchestration\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.lpi.org\\\/wp-content\\\/uploads\\\/2026\\\/03\\\/article-DevOps-Tools-Engineer-v2-Introduction-02-07.jpg\",\"datePublished\":\"2026-03-03T17:55:55+00:00\",\"dateModified\":\"2026-03-10T17:41:51+00:00\",\"description\":\"Container orchestration explained: Docker Compose, Podman Compose, and managing multi-container DevOps applications.\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.lpi.org\\\/it\\\/blog\\\/2026\\\/03\\\/03\\\/devops-tools-introduction-07-container-orchestration\\\/#breadcrumb\"},\"inLanguage\":\"it-IT\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.lpi.org\\\/it\\\/blog\\\/2026\\\/03\\\/03\\\/devops-tools-introduction-07-container-orchestration\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"it-IT\",\"@id\":\"https:\\\/\\\/www.lpi.org\\\/it\\\/blog\\\/2026\\\/03\\\/03\\\/devops-tools-introduction-07-container-orchestration\\\/#primaryimage\",\"url\":\"https:\\\/\\\/www.lpi.org\\\/wp-content\\\/uploads\\\/2026\\\/03\\\/article-DevOps-Tools-Engineer-v2-Introduction-02-07.jpg\",\"contentUrl\":\"https:\\\/\\\/www.lpi.org\\\/wp-content\\\/uploads\\\/2026\\\/03\\\/article-DevOps-Tools-Engineer-v2-Introduction-02-07.jpg\",\"width\":1440,\"height\":994,\"caption\":\"DevOps Tools Introduction #07: Container Orchestration\"},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.lpi.org\\\/it\\\/blog\\\/2026\\\/03\\\/03\\\/devops-tools-introduction-07-container-orchestration\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/www.lpi.org\\\/it\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"DevOps Tools Introduction #07: Container Orchestration\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/www.lpi.org\\\/it\\\/#website\",\"url\":\"https:\\\/\\\/www.lpi.org\\\/it\\\/\",\"name\":\"Linux Professional Institute (LPI)\",\"description\":\"\",\"publisher\":{\"@id\":\"https:\\\/\\\/www.lpi.org\\\/it\\\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/www.lpi.org\\\/it\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"it-IT\"},{\"@type\":\"Organization\",\"@id\":\"https:\\\/\\\/www.lpi.org\\\/it\\\/#organization\",\"name\":\"Linux Professional Institute (LPI)\",\"url\":\"https:\\\/\\\/www.lpi.org\\\/it\\\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"it-IT\",\"@id\":\"https:\\\/\\\/www.lpi.org\\\/it\\\/#\\\/schema\\\/logo\\\/image\\\/\",\"url\":\"https:\\\/\\\/www.lpi.org\\\/wp-content\\\/uploads\\\/2023\\\/04\\\/logo.png\",\"contentUrl\":\"https:\\\/\\\/www.lpi.org\\\/wp-content\\\/uploads\\\/2023\\\/04\\\/logo.png\",\"width\":496,\"height\":175,\"caption\":\"Linux Professional Institute (LPI)\"},\"image\":{\"@id\":\"https:\\\/\\\/www.lpi.org\\\/it\\\/#\\\/schema\\\/logo\\\/image\\\/\"},\"sameAs\":[\"https:\\\/\\\/www.facebook.com\\\/LPIConnect\",\"https:\\\/\\\/x.com\\\/lpiconnect\",\"https:\\\/\\\/www.linkedin.com\\\/company\\\/35136\",\"https:\\\/\\\/www.instagram.com\\\/lpi_org\\\/\",\"https:\\\/\\\/fosstodon.org\\\/@LPI\"]},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/www.lpi.org\\\/it\\\/#\\\/schema\\\/person\\\/87a340eca845e18d801667fd11e6937c\",\"name\":\"Fabian Thorns\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"it-IT\",\"@id\":\"https:\\\/\\\/www.lpi.org\\\/wp-content\\\/uploads\\\/2026\\\/01\\\/cropped-fabian-thorns-1920px-96x96.jpg583c90110e404d4e42f0be7307753074\",\"url\":\"https:\\\/\\\/www.lpi.org\\\/wp-content\\\/uploads\\\/2026\\\/01\\\/cropped-fabian-thorns-1920px-96x96.jpg\",\"contentUrl\":\"https:\\\/\\\/www.lpi.org\\\/wp-content\\\/uploads\\\/2026\\\/01\\\/cropped-fabian-thorns-1920px-96x96.jpg\",\"caption\":\"Fabian Thorns\"},\"description\":\"Fabian Thorns is the Director of Product Development at Linux Professional Institute, LPI. He is M.Sc. Business Information Systems, a regular speaker at open source events and the author of numerous articles and books. Fabian has been part of the exam development team since 2010. Connect with him on LinkedIn, XING\u00a0or via email (fthorns\u00a0at\u00a0www.lpi.org).\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"DevOps Tools Introduction #07: Container Orchestration - Linux Professional Institute (LPI)","description":"Container orchestration explained: Docker Compose, Podman Compose, and managing multi-container DevOps applications.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.lpi.org\/it\/blog\/2026\/03\/03\/devops-tools-introduction-07-container-orchestration\/","og_locale":"it_IT","og_type":"article","og_title":"DevOps Tools Introduction #07: Container Orchestration","og_description":"Container orchestration explained: Docker Compose, Podman Compose, and managing multi-container DevOps applications.","og_url":"https:\/\/www.lpi.org\/it\/blog\/2026\/03\/03\/devops-tools-introduction-07-container-orchestration\/","og_site_name":"Linux Professional Institute (LPI)","article_publisher":"https:\/\/www.facebook.com\/LPIConnect","article_published_time":"2026-03-03T17:55:55+00:00","article_modified_time":"2026-03-10T17:41:51+00:00","og_image":[{"width":1440,"height":994,"url":"https:\/\/www.lpi.org\/wp-content\/uploads\/2026\/03\/article-DevOps-Tools-Engineer-v2-Introduction-02-07.jpg","type":"image\/jpeg"}],"author":"Fabian Thorns, Uir\u00e1 Ribeiro","twitter_card":"summary_large_image","twitter_creator":"@lpiconnect","twitter_site":"@lpiconnect","twitter_misc":{"Scritto da":"Fabian Thorns","Tempo di lettura stimato":"7 minuti"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.lpi.org\/it\/blog\/2026\/03\/03\/devops-tools-introduction-07-container-orchestration\/#article","isPartOf":{"@id":"https:\/\/www.lpi.org\/it\/blog\/2026\/03\/03\/devops-tools-introduction-07-container-orchestration\/"},"author":{"name":"Fabian Thorns","@id":"https:\/\/www.lpi.org\/it\/#\/schema\/person\/87a340eca845e18d801667fd11e6937c"},"headline":"DevOps Tools Introduction #07: Container Orchestration","datePublished":"2026-03-03T17:55:55+00:00","dateModified":"2026-03-10T17:41:51+00:00","mainEntityOfPage":{"@id":"https:\/\/www.lpi.org\/it\/blog\/2026\/03\/03\/devops-tools-introduction-07-container-orchestration\/"},"wordCount":1503,"commentCount":0,"publisher":{"@id":"https:\/\/www.lpi.org\/it\/#organization"},"image":{"@id":"https:\/\/www.lpi.org\/it\/blog\/2026\/03\/03\/devops-tools-introduction-07-container-orchestration\/#primaryimage"},"thumbnailUrl":"https:\/\/www.lpi.org\/wp-content\/uploads\/2026\/03\/article-DevOps-Tools-Engineer-v2-Introduction-02-07.jpg","articleSection":["- None -"],"inLanguage":"it-IT","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.lpi.org\/it\/blog\/2026\/03\/03\/devops-tools-introduction-07-container-orchestration\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.lpi.org\/it\/blog\/2026\/03\/03\/devops-tools-introduction-07-container-orchestration\/","url":"https:\/\/www.lpi.org\/it\/blog\/2026\/03\/03\/devops-tools-introduction-07-container-orchestration\/","name":"DevOps Tools Introduction #07: Container Orchestration - Linux Professional Institute (LPI)","isPartOf":{"@id":"https:\/\/www.lpi.org\/it\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.lpi.org\/it\/blog\/2026\/03\/03\/devops-tools-introduction-07-container-orchestration\/#primaryimage"},"image":{"@id":"https:\/\/www.lpi.org\/it\/blog\/2026\/03\/03\/devops-tools-introduction-07-container-orchestration\/#primaryimage"},"thumbnailUrl":"https:\/\/www.lpi.org\/wp-content\/uploads\/2026\/03\/article-DevOps-Tools-Engineer-v2-Introduction-02-07.jpg","datePublished":"2026-03-03T17:55:55+00:00","dateModified":"2026-03-10T17:41:51+00:00","description":"Container orchestration explained: Docker Compose, Podman Compose, and managing multi-container DevOps applications.","breadcrumb":{"@id":"https:\/\/www.lpi.org\/it\/blog\/2026\/03\/03\/devops-tools-introduction-07-container-orchestration\/#breadcrumb"},"inLanguage":"it-IT","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.lpi.org\/it\/blog\/2026\/03\/03\/devops-tools-introduction-07-container-orchestration\/"]}]},{"@type":"ImageObject","inLanguage":"it-IT","@id":"https:\/\/www.lpi.org\/it\/blog\/2026\/03\/03\/devops-tools-introduction-07-container-orchestration\/#primaryimage","url":"https:\/\/www.lpi.org\/wp-content\/uploads\/2026\/03\/article-DevOps-Tools-Engineer-v2-Introduction-02-07.jpg","contentUrl":"https:\/\/www.lpi.org\/wp-content\/uploads\/2026\/03\/article-DevOps-Tools-Engineer-v2-Introduction-02-07.jpg","width":1440,"height":994,"caption":"DevOps Tools Introduction #07: Container Orchestration"},{"@type":"BreadcrumbList","@id":"https:\/\/www.lpi.org\/it\/blog\/2026\/03\/03\/devops-tools-introduction-07-container-orchestration\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.lpi.org\/it\/"},{"@type":"ListItem","position":2,"name":"DevOps Tools Introduction #07: Container Orchestration"}]},{"@type":"WebSite","@id":"https:\/\/www.lpi.org\/it\/#website","url":"https:\/\/www.lpi.org\/it\/","name":"Linux Professional Institute (LPI)","description":"","publisher":{"@id":"https:\/\/www.lpi.org\/it\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.lpi.org\/it\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"it-IT"},{"@type":"Organization","@id":"https:\/\/www.lpi.org\/it\/#organization","name":"Linux Professional Institute (LPI)","url":"https:\/\/www.lpi.org\/it\/","logo":{"@type":"ImageObject","inLanguage":"it-IT","@id":"https:\/\/www.lpi.org\/it\/#\/schema\/logo\/image\/","url":"https:\/\/www.lpi.org\/wp-content\/uploads\/2023\/04\/logo.png","contentUrl":"https:\/\/www.lpi.org\/wp-content\/uploads\/2023\/04\/logo.png","width":496,"height":175,"caption":"Linux Professional Institute (LPI)"},"image":{"@id":"https:\/\/www.lpi.org\/it\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/www.facebook.com\/LPIConnect","https:\/\/x.com\/lpiconnect","https:\/\/www.linkedin.com\/company\/35136","https:\/\/www.instagram.com\/lpi_org\/","https:\/\/fosstodon.org\/@LPI"]},{"@type":"Person","@id":"https:\/\/www.lpi.org\/it\/#\/schema\/person\/87a340eca845e18d801667fd11e6937c","name":"Fabian Thorns","image":{"@type":"ImageObject","inLanguage":"it-IT","@id":"https:\/\/www.lpi.org\/wp-content\/uploads\/2026\/01\/cropped-fabian-thorns-1920px-96x96.jpg583c90110e404d4e42f0be7307753074","url":"https:\/\/www.lpi.org\/wp-content\/uploads\/2026\/01\/cropped-fabian-thorns-1920px-96x96.jpg","contentUrl":"https:\/\/www.lpi.org\/wp-content\/uploads\/2026\/01\/cropped-fabian-thorns-1920px-96x96.jpg","caption":"Fabian Thorns"},"description":"Fabian Thorns is the Director of Product Development at Linux Professional Institute, LPI. He is M.Sc. Business Information Systems, a regular speaker at open source events and the author of numerous articles and books. Fabian has been part of the exam development team since 2010. Connect with him on LinkedIn, XING\u00a0or via email (fthorns\u00a0at\u00a0www.lpi.org)."}]}},"views":480,"authors":[{"term_id":540,"user_id":66,"is_guest":0,"slug":"fthornslpi-org","display_name":"Fabian Thorns","avatar_url":"https:\/\/www.lpi.org\/wp-content\/uploads\/2026\/01\/cropped-fabian-thorns-1920px-96x96.jpg","0":null,"1":"","2":"","3":"","4":"","5":"","6":"","7":"","8":""},{"term_id":571,"user_id":109,"is_guest":0,"slug":"uira-ribeiro","display_name":"Uir\u00e1 Ribeiro","avatar_url":"https:\/\/www.lpi.org\/wp-content\/uploads\/2024\/07\/cropped-cropped-uria-ribeiro-220x220-1-96x96.jpg","0":null,"1":"","2":"","3":"","4":"","5":"","6":"","7":"","8":""}],"_links":{"self":[{"href":"https:\/\/www.lpi.org\/it\/wp-json\/wp\/v2\/posts\/36404","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.lpi.org\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.lpi.org\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.lpi.org\/it\/wp-json\/wp\/v2\/users\/66"}],"replies":[{"embeddable":true,"href":"https:\/\/www.lpi.org\/it\/wp-json\/wp\/v2\/comments?post=36404"}],"version-history":[{"count":9,"href":"https:\/\/www.lpi.org\/it\/wp-json\/wp\/v2\/posts\/36404\/revisions"}],"predecessor-version":[{"id":36688,"href":"https:\/\/www.lpi.org\/it\/wp-json\/wp\/v2\/posts\/36404\/revisions\/36688"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.lpi.org\/it\/wp-json\/wp\/v2\/media\/36406"}],"wp:attachment":[{"href":"https:\/\/www.lpi.org\/it\/wp-json\/wp\/v2\/media?parent=36404"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.lpi.org\/it\/wp-json\/wp\/v2\/categories?post=36404"},{"taxonomy":"country","embeddable":true,"href":"https:\/\/www.lpi.org\/it\/wp-json\/wp\/v2\/country?post=36404"},{"taxonomy":"language","embeddable":true,"href":"https:\/\/www.lpi.org\/it\/wp-json\/wp\/v2\/language?post=36404"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.lpi.org\/it\/wp-json\/wp\/v2\/ppma_author?post=36404"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}