{"id":5951,"date":"2018-12-19T00:20:45","date_gmt":"2018-12-19T00:20:45","guid":{"rendered":"https:\/\/www.appservgrid.com\/paw92\/?p=5951"},"modified":"2018-12-28T22:06:32","modified_gmt":"2018-12-28T22:06:32","slug":"sharing-docker-containers-across-devops-environments","status":"publish","type":"post","link":"https:\/\/www.appservgrid.com\/paw92\/index.php\/2018\/12\/19\/sharing-docker-containers-across-devops-environments\/","title":{"rendered":"Sharing Docker Containers across DevOps Environments"},"content":{"rendered":"

Docker provides a powerful tool for creating lightweight images and
\ncontainerized processes, but did you know it can make your development
\nenvironment part of the DevOps pipeline too? Whether you’re managing
\ntens of thousands of servers in the cloud or are a software engineer looking
\nto incorporate Docker containers into the software development life
\ncycle, this article has a little something for everyone with a passion
\nfor Linux and Docker.<\/em><\/p>\n

In this article, I describe how Docker containers flow
\nthrough the DevOps pipeline. I also cover some advanced DevOps
\nconcepts (borrowed from object-oriented programming) on how to use
\ndependency injection and encapsulation to improve the DevOps process.
\nAnd finally, I show how containerization can be useful for the
\ndevelopment and testing process itself, rather than just as a
\nplace to serve up an application after it’s written.<\/p>\n

Introduction<\/h3>\n

Containers are hot in DevOps shops, and their benefits from an
\noperations and service delivery point of view have been covered well
\nelsewhere. If you want to build a Docker container or deploy a Docker
\nhost, container or swarm, a lot of information is available.
\nHowever, very few articles talk about how to develop<\/em> inside the Docker
\ncontainers that will be reused later in the DevOps pipeline, so that’s what
\nI focus on here.<\/p>\n

\"""\"<\/p>\n

Figure 1.
\nStages a Docker Container Moves Through in a Typical DevOps
\nPipeline<\/em><\/p>\n

Container-Based Development Workflows<\/h3>\n

Two common workflows exist for developing software for use inside Docker
\ncontainers:<\/p>\n

    \n
  1. Injecting development tools into an existing Docker container:
    \nthis is the best option for sharing a consistent development environment
    \nwith the same toolchain among multiple developers, and it can be used in
    \nconjunction with web-based development environments, such as Red Hat’s
    \ncodenvy.com or dockerized IDEs like Eclipse Che.<\/li>\n
  2. Bind-mounting a host directory onto the Docker container and using your
    \nexisting development tools on the host:
    \nthis is the simplest option, and it offers flexibility for developers
    \nto work with their own set of locally installed development tools.<\/li>\n<\/ol>\n

    Both workflows have advantages, but local mounting is inherently simpler. For
    \nthat reason, I focus on the mounting solution as “the simplest
    \nthing that could possibly work” here.<\/p>\n

    How Docker Containers Move between Environments<\/p>\n

    A core tenet of DevOps is that the source code and runtimes that will be used
    \nin production are the same as those used in development. In other words, the
    \nmost effective pipeline is one where the identical Docker image can be reused
    \nfor each stage of the pipeline.<\/p>\n

    \"""\"<\/p>\n

    Figure 2. Idealized Docker-Based DevOps Pipeline<\/em><\/p>\n

    The notion here is that each environment uses the same Docker image and code
    \nbase, regardless of where it’s running. Unlike systems such as Puppet, Chef
    \nor Ansible that converge systems to a defined state, an idealized Docker
    \npipeline makes duplicate copies (containers) of a fixed image in each
    \nenvironment. Ideally, the only artifact that really moves between
    \nenvironmental stages in a Docker-centric pipeline is the ID of a Docker image;
    \nall other artifacts should be shared between environments to ensure
    \nconsistency.<\/p>\n

    Handling Differences between Environments<\/p>\n

    In the real world, environmental stages can vary. As a case point, your QA and
    \nstaging environments may contain different DNS names, different firewall
    \nrules and almost certainly different data fixtures. Combat this
    \nper-environment drift by standardizing services across your different
    \nenvironments. For example, ensuring that DNS resolves “db1.example.com” and
    \n“db2.example.com” to the right IP addresses in each environment is much more
    \nDocker-friendly than relying on configuration file changes or injectable
    \ntemplates that point your application to differing IP addresses. However, when
    \nnecessary, you can set environment variables for each container rather than
    \nmaking stateful changes to the fixed image. These variables then can be
    \nmanaged in a variety of ways, including the following:<\/p>\n

      \n
    1. Environment variables set at container runtime from the command line.<\/li>\n
    2. Environment variables set at container runtime from a file.<\/li>\n
    3. Autodiscovery using etcd, Consul, Vault or similar.<\/li>\n<\/ol>\n

      Consider a Ruby microservice that runs inside a Docker container. The service
      \naccesses a database somewhere. In order to run the same Ruby image in each
      \ndifferent environment, but with environment-specific data passed in as
      \nvariables, your deployment orchestration tool might use a shell script like
      \nthis one, “Example Mircoservice Deployment”:<\/p>\n

      # Reuse the same image to create containers in each
      \n# environment.
      \ndocker pull ruby:latest<\/p>\n

      # Bash function that exports key environment
      \n# variables to the container, and then runs Ruby
      \n# inside the container to display the relevant
      \n# values.
      \nmicroservice () {
      \ndocker run -e STAGE -e DB –rm ruby
      \n\/usr\/local\/bin\/ruby -e
      \n‘printf(“STAGE: %s, DB: %sn”,
      \nENV[“STAGE”],
      \nENV[“DB”])’
      \n}<\/p>\n

      Table 1 shows an example of how environment-specific information
      \nfor Development, Quality Assurance and Production can be passed to
      \notherwise-identical containers using exported environment variables.<\/p>\n

      Table 1. Same Image with Injected Environment Variables<\/p>\n\n\n\n\n\n
      Development<\/td>\nQuality Assurance<\/td>\nProduction<\/td>\n<\/tr>\n<\/thead>\n
      export STAGE=dev DB=db1; microservice<\/td>\nexport STAGE=qa DB=db2; microservice<\/td>\nexport STAGE=prod DB=db3; microservice<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

      To see this in action, open a terminal with a Bash prompt and run the commands
      \nfrom the “Example Microservice Deployment” script above to pull the Ruby image onto your Docker
      \nhost and create a reusable shell function. Next, run each of the commands from
      \nthe table above in turn to set up the proper environment variables and execute
      \nthe function. You should see the output shown in Table 2 for each simulated
      \nenvironment.<\/p>\n

      Table 2. Containers in Each Environment Producing Appropriate
      \nResults<\/p>\n\n\n\n\n\n
      Development<\/td>\nQuality Assurance<\/td>\nProduction<\/td>\n<\/tr>\n<\/thead>\n
      STAGE: dev, DB: db1<\/td>\nSTAGE: qa, DB: db2<\/td>\nSTAGE: prod, DB: db3<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

      Despite being a rather simplistic example, what’s being accomplished is really
      \nquite extraordinary! This is DevOps tooling at its best: you’re re-using the
      \nsame image and deployment script to ensure maximum consistency, but each
      \ndeployed instance (a “container” in Docker parlance) is still being tuned to
      \noperate properly within its pipeline stage.<\/p>\n

      With this approach, you limit configuration drift and variance by ensuring
      \nthat the exact same image is re-used for each stage of the pipeline.
      \nFurthermore, each container varies only by the environment-specific data or
      \nartifacts injected into them, reducing the burden of maintaining multiple
      \nversions or per-environment architectures.<\/p>\n

      But What about External Systems?<\/h3>\n

      The previous simulation didn’t really connect to any services outside the
      \nDocker container. How well would this work if you needed to connect your
      \ncontainers to environment-specific things outside the container itself?<\/p>\n

      Next, I simulate a Docker container moving from development through other stages
      \nof the DevOps pipeline, using a different database with its own data in each
      \nenvironment. This requires a little prep work first.<\/p>\n

      First, create a workspace for the example files. You can do this by cloning
      \nthe examples from GitHub or by making a directory. As an example:<\/p>\n

      # Clone the examples from GitHub.
      \ngit clone
      \nhttps:\/\/github.com\/CodeGnome\/SDCAPS-Examples
      \ncd SDCAPS-Examples\/db<\/p>\n

      # Create a working directory yourself.
      \nmkdir -p SDCAPS-Examples\/db
      \ncd SDCAPS-Examples\/db<\/p>\n

      The following SQL files should be in the db directory if you cloned the
      \nexample repository. Otherwise, go ahead and create them now.<\/p>\n

      db1.sql:<\/p>\n

      — Development Database
      \nPRAGMA foreign_keys=OFF;
      \nBEGIN TRANSACTION;
      \nCREATE TABLE AppData (
      \nlogin TEXT UNIQUE NOT NULL,
      \nname TEXT,
      \npassword TEXT
      \n);
      \nINSERT INTO AppData
      \nVALUES (‘root’,’developers’,’dev_password’),
      \n(‘dev’,’developers’,’dev_password’);
      \nCOMMIT;<\/p>\n

      db2.sql:<\/p>\n

      — Quality Assurance (QA) Database
      \nPRAGMA foreign_keys=OFF;
      \nBEGIN TRANSACTION;
      \nCREATE TABLE AppData (
      \nlogin TEXT UNIQUE NOT NULL,
      \nname TEXT,
      \npassword TEXT
      \n);
      \nINSERT INTO AppData
      \nVALUES (‘root’,’qa admins’,’admin_password’),
      \n(‘test’,’qa testers’,’user_password’);
      \nCOMMIT;<\/p>\n

      db3.sql:<\/p>\n

      — Production Database
      \nPRAGMA foreign_keys=OFF;
      \nBEGIN TRANSACTION;
      \nCREATE TABLE AppData (
      \nlogin TEXT UNIQUE NOT NULL,
      \nname TEXT,
      \npassword TEXT
      \n);
      \nINSERT INTO AppData
      \nVALUES (‘root’,’production’,
      \n‘$1$Ax6DIG\/K$TDPdujixy5DDscpTWD5HU0’),
      \n(‘deploy’,’devops deploy tools’,
      \n‘$1$hgTsycNO$FmJInHWROtkX6q7eWiJ1p\/’);
      \nCOMMIT;<\/p>\n

      Next, you need a small utility to create (or re-create) the various SQLite
      \ndatabases. This is really just a convenience script, so if you prefer to
      \ninitialize or load the SQL by hand or with another tool, go right ahead:<\/p>\n

      #!\/usr\/bin\/env bash<\/p>\n

      # You assume the database files will be stored in an
      \n# immediate subdirectory named “db” but you can
      \n# override this using an environment variable.
      \n: “$”
      \ncd “$DATABASE_DIR”<\/p>\n

      # Scan for the -f flag. If the flag is found, and if
      \n# there are matching filenames, verbosely remove the
      \n# existing database files.
      \npattern='(^|[[:space:]])-f([[:space:]]|$)’
      \nif [[ “$*” =~ $pattern ]] &&
      \ncompgen -o filenames -G ‘db?’ >&-
      \nthen
      \necho “Removing existing database files …”
      \nrm -v db? 2> \/dev\/null
      \necho
      \nfi<\/p>\n

      # Process each SQL dump in the current directory.
      \necho “Creating database files from SQL …”
      \nfor sql_dump in *.sql; do
      \ndb_filename=”$”
      \nif [[ ! -f “$db_filename” ]]; then
      \nsqlite3 “$db_filename” < “$sql_dump” &&
      \necho “$db_filename created”
      \nelse
      \necho “$db_filename already exists”
      \nfi
      \ndone<\/p>\n

      When you run .\/create_databases.sh, you should see:<\/p>\n

      Creating database files from SQL …
      \ndb1 created
      \ndb2 created
      \ndb3 created<\/p>\n

      If the utility script reports that the database files already exist, or if you
      \nwant to reset the database files to their initial state, you can call
      \nthe script again with the -f flag to re-create them from the associated .sql
      \nfiles.<\/p>\n

      Creating a Linux Password<\/h3>\n

      You probably noticed that some of the SQL files contained clear-text
      \npasswords while others have valid Linux password hashes. For the
      \npurposes of this article, that’s largely a contrivance to ensure that you have
      \ndifferent data in each database and to make it easy to tell which
      \ndatabase you’re looking at from the data itself.<\/p>\n

      For security though, it’s usually best to ensure that you have a
      \nproperly hashed password in any source files you may store. There are a
      \nnumber of ways to generate such passwords, but the OpenSSL library makes
      \nit easy to generate salted and hashed passwords from the command line.<\/p>\n

      Tip: for optimum security, don’t include your desired password or
      \npassphrase as an argument to OpenSSL on the command line, as it could
      \nthen be seen in the process list. Instead, allow OpenSSL to prompt you
      \nwith Password: and be sure to use a strong passphrase.<\/em><\/p>\n

      To generate a salted MD5 password with OpenSSL:<\/p>\n

      $ openssl passwd
      \n-1
      \n-salt “$(openssl rand -base64 6)”
      \nPassword:<\/p>\n

      Then you can paste the salted hash into \/etc\/shadow, an SQL file, utility
      \nscript or wherever else you may need it.<\/p>\n

      Simulating Deployment inside the Development Stage<\/h3>\n

      Now that you have some external resources to experiment with, you’re ready to
      \nsimulate a deployment. Let’s start by running a container in your development
      \nenvironment. I follow some DevOps best practices here and use fixed image IDs
      \nand defined gem versions.<\/p>\n

      DevOps Best Practices for Docker Image IDs<\/p>\n

      To ensure that you’re re-using the same image across pipeline stages,
      \nalways use an image ID rather than a named tag or symbolic reference
      \nwhen pulling images. For example, while the “latest” tag might point to
      \ndifferent versions of a Docker image over time, the SHA-256 identifier
      \nof an image version remains constant and also provides automatic
      \nvalidation as a checksum for downloaded images.<\/p>\n

      Furthermore, you always should use a fixed ID for assets you’re
      \ninjecting into your containers. Note how you specify a specific version
      \nof the SQLite3 Ruby gem to inject into the container at each stage. This
      \nensures that each pipeline stage has the same version, regardless of
      \nwhether the most current version of the gem from a RubyGems repository
      \nchanges between one container deployment and the next.<\/p>\n

      Getting a Docker Image ID<\/p>\n

      When you pull a Docker image, such as ruby:latest, Docker will report
      \nthe digest of the image on standard output:<\/p>\n

      $ docker pull ruby:latest
      \nlatest: Pulling from library\/ruby
      \nDigest:
      \nsha256:eed291437be80359321bf66a842d4d542a789e
      \n\u21aa687b38c31bd1659065b2906778
      \nStatus: Image is up to date for ruby:latest<\/p>\n

      If you want to find the ID for an image you’ve already pulled, you can
      \nuse the inspect sub-command to extract the digest from Docker’s JSON
      \noutput\u2014for example:<\/p>\n

      $ docker inspect
      \n–format='{}’
      \nruby:latest
      \nruby@sha256:eed291437be80359321bf66a842d4d542a789
      \n\u21aae687b38c31bd1659065b2906778<\/p>\n

      First, you export the appropriate environment variables for development. These
      \nvalues will override the defaults set by your deployment script and affect the
      \nbehavior of your sample application:<\/p>\n

      # Export values we want accessible inside the Docker
      \n# container.
      \nexport STAGE=”dev” DB=”db1″<\/p>\n

      Next, implement a script called container_deploy.sh that will simulate deployment across multiple
      \nenvironments. This is an example of the work that your deployment pipeline or
      \norchestration engine should do when instantiating containers for each
      \nstage:<\/p>\n

      #!\/usr\/bin\/env bash<\/p>\n

      set -e<\/p>\n

      ####################################################
      \n# Default shell and environment variables.
      \n####################################################
      \n# Quick hack to build the 64-character image ID
      \n# (which is really a SHA-256 hash) within a
      \n# magazine’s line-length limitations.
      \nhash_segments=(
      \n“eed291437be80359321bf66a842d4d54”
      \n“2a789e687b38c31bd1659065b2906778”
      \n)
      \nprintf -v id “%s” “$”<\/p>\n

      # Default Ruby image ID to use if not overridden
      \n# from the script’s environment.
      \n: “$”<\/p>\n

      # Fixed version of the SQLite3 gem.
      \n: “$”<\/p>\n

      # Default pipeline stage (e.g. dev, qa, prod).
      \n: “$”<\/p>\n

      # Default database to use (e.g. db1, db2, db3).
      \n: “$”<\/p>\n

      # Export values that should be visible inside the
      \n# container.
      \nexport STAGE DB<\/p>\n

      ####################################################
      \n# Setup and run Docker container.
      \n####################################################
      \n# Remove the Ruby container when script exits,
      \n# regardless of exit status unless DEBUG is set.
      \ncleanup () {
      \nlocal id msg1 msg2 msg3
      \nid=”$container_id”
      \nif [[ ! -v DEBUG ]]; then
      \ndocker rm –force “$id” >&-
      \nelse
      \nmsg1=”DEBUG was set.”
      \nmsg2=”Debug the container with:”
      \nmsg3=” docker exec -it $id bash”
      \nprintf “n%sn%sn%sn”
      \n“$msg1”
      \n“$msg2”
      \n“$msg3”
      \n> \/dev\/stderr
      \nfi
      \n}
      \ntrap “cleanup” EXIT<\/p>\n

      # Set up a container, including environment
      \n# variables and volumes mounted from the local host.
      \ndocker run
      \n-d
      \n-e STAGE
      \n-e DB
      \n-v “$\/db}”:\/srv\/db
      \n–init
      \n“ruby@sha256:$IMAGE_ID”
      \ntail -f \/dev\/null >&-<\/p>\n

      # Capture the container ID of the last container
      \n# started.
      \ncontainer_id=$(docker ps -ql)<\/p>\n

      # Inject a fixed version of the database gem into
      \n# the running container.
      \necho “Injecting gem into container…”
      \ndocker exec “$container_id”
      \ngem install sqlite3 -v “$SQLITE3_VERSION” &&
      \necho<\/p>\n

      # Define a Ruby script to run inside our container.
      \n#
      \n# The script will output the environment variables
      \n# we’ve set, and then display contents of the
      \n# database defined in the DB environment variable.
      \nruby_script=’
      \nrequire “sqlite3”<\/p>\n

      puts %Q(DevOps pipeline stage: #)
      \nputs %Q(Database for this stage: #)
      \nputs
      \nputs “Data stored in this database:”<\/p>\n

      Dir.chdir “\/srv\/db”
      \ndb = SQLite3::Database.open ENV[“DB”]
      \nquery = “SELECT rowid, * FROM AppData”
      \ndb.execute(query) do |row|
      \nprint ” ” * 4
      \nputs row.join(“, “)
      \nend
      \n‘<\/p>\n

      # Execute the Ruby script inside the running
      \n# container.
      \ndocker exec “$container_id” ruby -e “$ruby_script”<\/p>\n

      There are a few things to note about this script. First and foremost, your
      \nreal-world needs may be either simpler or more complex than this script
      \nprovides for. Nevertheless, it provides a reasonable baseline on which you can
      \nbuild.<\/p>\n

      Second, you may have noticed the use of the tail command when creating the
      \nDocker container. This is a common trick used for building containers that
      \ndon’t have a long-running application to keep the container in a running
      \nstate. Because you are re-entering the container using multiple
      \nexec commands,
      \nand because your example Ruby application runs once and exits,
      \ntail sidesteps a
      \nlot of ugly hacks needed to restart the container continually or keep it
      \nrunning while debugging.<\/p>\n

      Go ahead and run the script now. You should see the same output as listed
      \nbelow:<\/p>\n

      $ .\/container_deploy.sh
      \nBuilding native extensions. This could take a while…
      \nSuccessfully installed sqlite3-1.3.13
      \n1 gem installed<\/p>\n

      DevOps pipeline stage: dev
      \nDatabase for this stage: db1<\/p>\n

      Data stored in this database:
      \n1, root, developers, dev_password
      \n2, dev, developers, dev_password<\/p>\n

      Simulating Deployment across Environments<\/p>\n

      Now you’re ready to move on to something more ambitious. In the preceding
      \nexample, you deployed a container to the development environment. The Ruby
      \napplication running inside the container used the development database. The
      \npower of this approach is that the exact same process can be re-used for each
      \npipeline stage, and the only thing you need to change is the database to
      \nwhich the
      \napplication points.<\/p>\n

      In actual usage, your DevOps configuration management or orchestration engine
      \nwould handle setting up the correct environment variables for each stage of
      \nthe pipeline. To simulate deployment to multiple environments, populate an
      \nassociative array in Bash with the values each stage will need and then run
      \nthe script in a for loop:<\/p>\n

      declare -A env_db
      \nenv_db=([dev]=db1 [qa]=db2 [prod]=db3)<\/p>\n

      for env in dev qa prod; do
      \nexport STAGE=”$env” DB=”$”
      \nprintf “%sn” “Deploying to $ …”
      \n.\/container_deploy.sh
      \ndone<\/p>\n

      This stage-specific approach has a number of benefits from a DevOps point of
      \nview. That’s because:<\/p>\n

        \n
      1. The image ID deployed is identical across all pipeline stages.<\/li>\n
      2. A more complex application can “do the right thing” based on the value of
        \nSTAGE and DB (or other values) injected into the container at runtime.<\/li>\n
      3. The container is connected to the host filesystem the same way at each
        \nstage, so you can re-use source code or versioned artifacts pulled from Git,
        \nNexus or other repositories without making changes to the image or
        \ncontainer.<\/li>\n
      4. The switcheroo magic for pointing to the right external resources is
        \nhandled by your deployment script (in this case, container_deploy.sh) rather
        \nthan by making changes to your image, application or
        \ninfrastructure.<\/li>\n
      5. This solution is great if your goal is to trap most of the complexity in your
        \ndeployment tools or pipeline orchestration engine. However, a small refinement
        \nwould allow you to push the remaining complexity onto the pipeline
        \ninfrastructure instead.<\/li>\n<\/ol>\n

        Imagine for a moment that you have a more complex application than the one
        \nyou’ve been working with here. Maybe your QA or staging environments have large
        \ndata sets that you don’t want to re-create on local hosts, or maybe you need to point
        \nat a network resource that may move around at runtime. You can handle this by
        \nusing a well known name that is resolved by a external resource instead.<\/p>\n

        You can show this at the filesystem level by using a symlink. The benefit of
        \nthis approach is that the application and container no longer need to know
        \nanything about which database is present, because the database is always named
        \n“db”. Consider the following:<\/p>\n

        declare -A env_db
        \nenv_db=([dev]=db1 [qa]=db2 [prod]=db3)
        \nfor env in dev qa prod; do
        \nprintf “%sn” “Deploying to $ …”
        \n(cd db; ln -fs “$” db)
        \nexport STAGE=”$env” DB=”db”
        \n.\/container_deploy.sh
        \ndone<\/p>\n

        Likewise, you can configure your Domain Name Service (DNS) or a Virtual IP
        \n(VIP) on your network to ensure that the right database host or cluster is
        \nused for each stage. As an example, you might ensure that db.example.com
        \nresolves to a different IP address at each pipeline stage.<\/p>\n

        Sadly, the complexity of managing multiple environments never truly goes
        \naway\u2014it just hopefully gets abstracted to the right level for your
        \norganization. Think of your objective as similar to some object-oriented
        \nprogramming (OOP) best practices: you’re looking to create pipelines that
        \nminimize things that change and to allow applications and tools to rely on a
        \nstable interface. When changes are unavoidable, the goal is to keep the scope
        \nof what might change as small as possible and to hide the ugly details from
        \nyour tools to the greatest extent that you can.<\/p>\n

        If you have thousands or tens of thousands of servers, it’s often better to
        \nchange a couple DNS entries without downtime rather than rebuild or
        \nredeploy 10,000 application containers. Of course, there are always
        \ncounter-examples, so consider the trade-offs and make the best decisions you
        \ncan to encapsulate any unavoidable complexity.<\/p>\n

        Developing inside Your Container<\/h3>\n

        I’ve spent a lot of time explaining how to ensure that your development
        \ncontainers look like the containers in use in other stages of the pipeline.
        \nBut have I really described how to develop inside these
        \ncontainers? It turns out I’ve actually covered the essentials, but you need to
        \nshift your perspective a little to put it all together.<\/p>\n

        The same processes used to deploy containers in the previous sections also
        \nallow you to work inside a container. In particular, the previous examples have
        \ntouched on how to bind-mount code and artifacts from the host’s filesystem
        \ninside a container using the -v or –volume flags. That’s how
        \nthe container_deploy.sh script mounts database files on \/srv\/db inside the container. The
        \nsame mechanism can be used to mount source code, and the Docker
        \nexec command
        \nthen can be used to start a shell, editor or other development process inside
        \nthe container.<\/p>\n

        The develop.sh utility script is designed to showcase this ability. When you
        \nrun it, the script creates a Docker container and drops you into a Ruby shell
        \ninside the container. Go ahead and run .\/develop.sh now:<\/p>\n

        #!\/usr\/bin\/env bash<\/p>\n

        id=”eed291437be80359321bf66a842d4d54″
        \nid+=”2a789e687b38c31bd1659065b2906778″
        \n: “$”
        \n: “$”
        \n: “$”
        \n: “$”<\/p>\n

        export DB STAGE<\/p>\n

        echo “Launching ‘$STAGE’ container…”
        \ndocker run
        \n-d
        \n-e DB
        \n-e STAGE
        \n-v “$”:\/usr\/local\/src
        \n-v “$\/db}”:\/srv\/db
        \n–init
        \n“ruby@sha256:$IMAGE_ID”
        \ntail -f \/dev\/null >&-<\/p>\n

        container_id=$(docker ps -ql)<\/p>\n

        show_cmd () {
        \nenter=”docker exec -it $container_id bash”
        \nclean=”docker rm –force $container_id”
        \necho -ne
        \n“nRe-enter container with:nt$”
        \necho -ne
        \n“nClean up container with:nt$n”
        \n}
        \ntrap ‘show_cmd’ EXIT<\/p>\n

        docker exec “$container_id”
        \ngem install sqlite3 -v “$SQLITE3_VERSION” >&-<\/p>\n

        docker exec
        \n-e DB
        \n-e STAGE
        \n-it “$container_id”
        \nirb -I \/usr\/local\/src -r sqlite3<\/p>\n

        Once inside the container’s Ruby read-evaluate-print loop (REPL), you can
        \ndevelop your source code as you normally would from outside the container. Any
        \nsource code changes will be seen immediately from inside the container at the
        \ndefined mountpoint of \/usr\/local\/src. You then can test your code using the
        \nsame runtime that will be available later in your pipeline.<\/p>\n

        Let’s try a few basic things just to get a feel for how this works. Ensure
        \nthat you
        \nhave the sample Ruby files installed in the same directory as develop.sh. You
        \ndon’t actually have to know (or care) about Ruby programming for this exercise
        \nto have value. The point is to show how your containerized applications can
        \ninteract with your host’s development environment.<\/p>\n

        example_query.rb:<\/p>\n

        # Ruby module to query the table name via SQL.
        \nmodule ExampleQuery
        \ndef self.table_name
        \npath = “\/srv\/db\/#”
        \ndb = SQLite3::Database.new path
        \nsql =<<-‘SQL’
        \nSELECT name FROM sqlite_master
        \nWHERE type=’table’
        \nLIMIT 1;
        \nSQL
        \ndb.get_first_value sql
        \nend
        \nend<\/p>\n

        source_list.rb:<\/p>\n

        # Ruby module to list files in the source directory
        \n# that’s mounted inside your container.
        \nmodule SourceList
        \ndef self.array
        \nDir[‘\/usr\/local\/src\/*’]
        \nend<\/p>\n

        def self.print
        \nputs self.array
        \nend
        \nend<\/p>\n

        At the IRB prompt (irb(main):001:0>), try the following code to make
        \nsure everything is working as expected:<\/p>\n

        # returns “AppData”
        \nload ‘example_query.rb’; ExampleQuery.table_name<\/p>\n

        # prints file list to standard output; returns nil
        \nload ‘source_list.rb’; SourceList.print<\/p>\n

        In both cases, Ruby source code is being read from \/usr\/local\/src, which is
        \nbound to the current working directory of the develop.sh script. While working
        \nin development, you could edit those files in any fashion you chose and then
        \nload them again into IRB. It’s practically magic!<\/p>\n

        It works the other way too. From inside the container, you can use any tool
        \nor feature of the container to interact with your source directory on the host
        \nsystem. For example, you can download the familiar Docker whale logo and make
        \nit available to your development environment from the container’s Ruby
        \nREPL:<\/p>\n

        Dir.chdir ‘\/usr\/local\/src’
        \ncmd =
        \n“curl -sLO ” <<
        \n“https:\/\/www.docker.com” <<
        \n“\/sites\/default\/files” <<
        \n“\/vertical_large.png”
        \nsystem cmd<\/p>\n

        Both \/usr\/local\/src and the matching host directory now contain the
        \nvertical_large.png graphic file. You’ve added a file to your source tree from
        \ninside the Docker container!<\/p>\n

        \"""\"<\/p>\n

        Figure 3.
        \nDocker Logo on the Host Filesystem and<\/em> inside the Container<\/em><\/p>\n

        When you press Ctrl-D to exit the REPL, the develop.sh script informs you how to
        \nreconnect to the still-running container, as well as how to delete the
        \ncontainer when you’re done with it. Output will look similar to the following:<\/p>\n

        Re-enter container with:
        \ndocker exec -it 9a2c94ebdee8 bash
        \nClean up container with:
        \ndocker rm –force 9a2c94ebdee8<\/p>\n

        As a practical matter, remember that the develop.sh script is setting Ruby’s
        \nLOAD_PATH and requiring the sqlite3 gem for you when launching the first
        \ninstance of IRB. If you exit that process, launching another instance of IRB
        \nwith docker exec or from a Bash shell inside the container may not do what
        \nyou expect. Be sure to run irb -I \/usr\/local\/src -r sqlite3 to
        \nre-create that
        \nfirst smooth experience!<\/p>\n

        Wrapping Up<\/h3>\n

        I covered how Docker containers typically flow through the DevOps pipeline,
        \nfrom development all the way to production. I looked at some common practices
        \nfor managing the differences between pipeline stages and how to use
        \nstage-specific data and artifacts in a reproducible and automated fashion.
        \nAlong the way, you also may have learned a little more about Docker commands,
        \nBash scripting and the Ruby REPL.<\/p>\n

        I hope it’s been an interesting journey. I know I’ve enjoyed sharing it with
        \nyou, and I sincerely hope I’ve left your DevOps and containerization toolboxes
        \njust a little bit larger in the process.<\/p>\n

        Source<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

        Docker provides a powerful tool for creating lightweight images and containerized processes, but did you know it can make your development environment part of the DevOps pipeline too? Whether you’re managing tens of thousands of servers in the cloud or are a software engineer looking to incorporate Docker containers into the software development life cycle, … <\/p>\n

        Continue reading “Sharing Docker Containers across DevOps Environments”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-5951","post","type-post","status-publish","format-standard","hentry","category-linux"],"_links":{"self":[{"href":"https:\/\/www.appservgrid.com\/paw92\/index.php\/wp-json\/wp\/v2\/posts\/5951","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.appservgrid.com\/paw92\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.appservgrid.com\/paw92\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.appservgrid.com\/paw92\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.appservgrid.com\/paw92\/index.php\/wp-json\/wp\/v2\/comments?post=5951"}],"version-history":[{"count":1,"href":"https:\/\/www.appservgrid.com\/paw92\/index.php\/wp-json\/wp\/v2\/posts\/5951\/revisions"}],"predecessor-version":[{"id":6566,"href":"https:\/\/www.appservgrid.com\/paw92\/index.php\/wp-json\/wp\/v2\/posts\/5951\/revisions\/6566"}],"wp:attachment":[{"href":"https:\/\/www.appservgrid.com\/paw92\/index.php\/wp-json\/wp\/v2\/media?parent=5951"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.appservgrid.com\/paw92\/index.php\/wp-json\/wp\/v2\/categories?post=5951"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.appservgrid.com\/paw92\/index.php\/wp-json\/wp\/v2\/tags?post=5951"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}