Answers: <p>From what I understand of <a href="https://stackoverflow.com/questions/28734086/how-to-move-docker-containers-between-different-hosts">https://stackoverflow.com/questions/28734086/how-to-move-docker-containers-between-different-hosts</a>, <code>docker export</code> will only save the container filesystem. But no metadata such as the default command, leading to that error when you try to run the imported archive:</p>
  
  <pre><code>sh# IMAGE=$(docker import phpbb.tar)                                                                                                                                       
  sh# docker run "${IMAGE}"
  docker: Error response from daemon: No command specified.
  </code></pre>
  
  <p><br>
  Given my need, it is sufficient to <code>docker commit</code> the container to a new image, then <code>docker save</code> the image, and finally <code>docker load</code> and <code>docker run</code> it on the new host:</p>
  
  <pre><code>old# docker commit CONTAINER name:tag
  old# docker save name:tag |gzip &gt; archive.tar.gz
  old# scp archive.tar.gz root@new:.
  </code></pre>
  
  
  
  <pre><code>new# docker load &lt; archive.tar.gz
  new# docker run name:latest
  </code></pre>
  
  <p>It is important to save the image by repository <code>name:tag</code> and not by id to preserve the tag in the archive.</p>
  
Answers: CC BY-SA 4.0
Answers: 2019-02-14T18:12:50.533Z
Answers: 2019-02-15T16:18:28.760Z
Answers: 2019-02-15T16:18:28.760Z
Answers: Sylvain Leroux
Body: <p>We have a forum application made of two containers: a container for the database, and another one for the bulletin board application itself. Both containers are running on the same host for quite some time now. That application does not follow the "microservice" architecture since the database files are stored in the writable layer of the database container. And the configuration settings of the forum were directly set up in the writable layer of the bulletin board application.</p>
  
  <p>We would like to migrate that forum to a different host since the current server has reached end-of-life. We see two ways of doing that:</p>
  
  <ul>
  <li>using <code>docker commit</code> to make an image of both containers, then uploading those images to a repository and pulling them back from the new host.</li>
  <li>using <code>docker export</code> to create archives of the container filesystems, and importing them on the new host.</li>
  </ul>
  
  <p>What are the pro and cons of both approaches for ad-hoc container migration? Is there a better-suited solution for our specific needs?</p>
  
Comments: CC BY-SA 4.0
Comments: 2019-02-14T06:42:23.147Z
Comments: https://stackoverflow.com/questions/28734086/how-to-move-docker-containers-between-different-hosts
Comments: Marged
Comments: CC BY-SA 4.0
Comments: 2019-02-14T11:59:04.097Z
Comments: @Marged yes, I've seen that. But the problem is not about knowing which command I _can_ use. But which one I _should_ use. Said simpler, is there a specific advantage in committing the image I would miss by merely exporting a tarball?
Comments: Sylvain Leroux
Comments: CC BY-SA 4.0
Comments: 2019-02-14T17:10:58.167Z
Comments: I think the advantages are mentioned rather clearly. At least when it comes to speed, size and completeness
Comments: Marged
Tags: <docker><migration>
Title: How to move a containerized application to a different host?
UserDisplayName: Sylvain Leroux
ThreadText: # How to move a containerized application to a different host?
  
  (Asked by: username_0 on 2019-02-13)
  
  We have a forum application made of two containers: a container for the database, and another one for the bulletin board application itself. Both containers are running on the same host for quite some time now. That application does not follow the "microservice" architecture since the database files are stored in the writable layer of the database container. And the configuration settings of the forum were directly set up in the writable layer of the bulletin board application.
  
  We would like to migrate that forum to a different host since the current server has reached end-of-life. We see two ways of doing that:
  
  * using `docker commit` to make an image of both containers, then uploading those images to a repository and pulling them back from the new host.
  * using `docker export` to create archives of the container filesystems, and importing them on the new host.
  
  What are the pro and cons of both approaches for ad-hoc container migration? Is there a better-suited solution for our specific needs?
  
  **Tags:** docker, migration
  
  > **Comments:**
  > **username_1**: https://stackoverflow.com/questions/28734086/how-to-move-docker-containers-between-different-hosts  
  > **username_0**: @username_1 yes, I've seen that. But the problem is not about knowing which command I _can_ use. But which one I _should_ use. Said simpler, is there a specific advantage in committing the image I would miss by merely exporting a tarball?  
  > **username_1**: I think the advantages are mentioned rather clearly. At least when it comes to speed, size and completeness  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_0 on 2019-02-14. Score: 2 | Accepted answer
  
  From what I understand of <https://stackoverflow.com/questions/28734086/how-to-move-docker-containers-between-different-hosts>, `docker export` will only save the container filesystem. But no metadata such as the default command, leading to that error when you try to run the imported archive:
  
  ```
  sh# IMAGE=$(docker import phpbb.tar)                                                                                                                                       
  sh# docker run "${IMAGE}"
  docker: Error response from daemon: No command specified.
  
  ```
  
  Given my need, it is sufficient to `docker commit` the container to a new image, then `docker save` the image, and finally `docker load` and `docker run` it on the new host:
  
  ```
  old# docker commit CONTAINER name:tag
  old# docker save name:tag |gzip > archive.tar.gz
  old# scp archive.tar.gz root@new:.
  
  ```
  
  ```
  new# docker load < archive.tar.gz
  new# docker run name:latest
  
  ```
  
  It is important to save the image by repository `name:tag` and not by id to preserve the tag in the archive.
  
  
  ---
  
  