Answers: <p>Creating a Docker image from a pre-populated database container — is not an anti-pattern. In fact, for your use case, it can be an efficient solution, especially when the data is static and read-only.</p>
  
Answers: CC BY-SA 4.0
Answers: 2024-11-30T03:27:15.857Z
Answers: Thank you @qodirov-shohijahon - that is very helpful.  I'll see if I cannot optimize the pipeline this weekend.
Answers: Not a machine
Answers: CC BY-SA 4.0
Answers: 2024-11-28T10:40:58.760Z
Answers: 2024-11-28T10:40:58.760Z
Answers: Qodirov Shohijahon
Body: <p>I have a small Docker container running a static (read-only) database which contains data for drop-down menus and web ui content such as counties per state, zip codes, etc.</p>
  <p>The image is generated whenever the database content is changed via a commit pipeline. Currently, the database tables are populated when the container first starts using SQL scripts I created in docker-entrypoint-initdb.</p>
  <p>So far, this is working well. However, there is a container startup cost associated with running the initdb scripts and I am considering starting the container as part of the pipeline and then creating an image from the container once the database tables are populated.</p>
  <p>Is this a container anti-pattern? It feels a little unnatural from a pipeline/container perspective but it would allow containers to spin up faster and be purely stateless.</p>
  <p>I strongly prefer not to use a volume for this application as it really isn’t needed and it adds complexity to the deployed application.</p>
  
Tags: <docker>
Title: Optimizing a containerized database initialization and startup
UserDisplayName: Not a machine
ThreadText: # Optimizing a containerized database initialization and startup
  
  (Asked by: username_0 on 2024-11-27)
  
  I have a small Docker container running a static (read-only) database which contains data for drop-down menus and web ui content such as counties per state, zip codes, etc.
  
  The image is generated whenever the database content is changed via a commit pipeline. Currently, the database tables are populated when the container first starts using SQL scripts I created in docker-entrypoint-initdb.
  
  So far, this is working well. However, there is a container startup cost associated with running the initdb scripts and I am considering starting the container as part of the pipeline and then creating an image from the container once the database tables are populated.
  
  Is this a container anti-pattern? It feels a little unnatural from a pipeline/container perspective but it would allow containers to spin up faster and be purely stateless.
  
  I strongly prefer not to use a volume for this application as it really isn’t needed and it adds complexity to the deployed application.
  
  **Tags:** docker
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2024-11-28. Score: 1
  
  Creating a Docker image from a pre-populated database container — is not an anti-pattern. In fact, for your use case, it can be an efficient solution, especially when the data is static and read-only.
  
  > **Comments:**
  > **username_0**: Thank you @username_1-username_1 - that is very helpful.  I'll see if I cannot optimize the pipeline this weekend.  
  
  ---
  
  