Docker is an amazing tool for developers. It allows us to build and replicate images on any host, removing the inconsistencies of dev environments and reducing onboarding timelines considerably.
To provide an example of how you might move to containerized development, I built a simple todo API using NodeJS, Express, and PostgreSQL using Docker Compose for development, testing, and eventually in my CI/CD pipeline.
In a two-part series, I will cover the development and pipeline creation steps. In this post, I will cover the first part: developing and testing with Docker Compose.
This tutorial requires you to have a few items before you can get started.
The todo app here is essentially a stand-in, and you could replace it with your own application. Some of the setup here is specific for this application, and the needs of your application may not be covered, but it should be a good starting point for you to get the concepts needed to Dockerize your own applications.
Once you have everything set up, you can move on to the next section.
At the foundation of any Dockerized application, you will find a
Dockerfile contains all of the instructions used to build out the application image. You can set this up by installing NodeJS and all of its dependencies; however the Docker ecosystem has an image repository (the Docker Store) with a NodeJS image already created and ready to use.
In the root directory of the application, create a new
/> touch Dockerfile
Open the newly created
Dockerfile in your favorite editor. The first instruction, FROM, will tell Docker to use the prebuilt NodeJS image. There are several choices, but this project uses the
If you run
docker build ., you will see something similar to the following:
Sending build context to Docker daemon 249.3 kB Step 1/1 : FROM node:7.7.2-alpine 7.7.2-alpine: Pulling from library/node 709515475419: Pull complete 1a7746e437f7: Pull complete 662ac7b95f9d: Pull complete Digest: sha256:6dcd183eaf2852dd8c1079642c04cc2d1f777e4b34f2a534cc0ad328a98d7f73 Status: Downloaded newer image for node:7.7.2-alpine ---> 95b4a6de40c3 Successfully built 95b4a6de40c3
With only one instruction in the
Dockerfile, this doesn’t do too much, but it does show you the build process without too much happening. At this point, you now have an image created, and running
docker images will show you the images you have available:
REPOSITORY TAG IMAGE ID CREATED SIZE node 7.7.2-alpine 95b4a6de40c3 6 weeks ago 59.2 MB
Dockerfile needs more instructions to build out the application. Currently it’s only creating an image with NodeJS installed, but we still need our application code to run inside the container. Let’s add some more instructions to do this and build this image again.
This particular Docker file uses
WORKDIR. You can read more about those on Docker’s reference page to get a deeper understanding.
Let’s add the instructions to the
FROM node:7.7.2-alpine WORKDIR /usr/app COPY package.json . RUN npm install --quiet COPY . .
Here is what is happening:
You can now run
docker build . again and see the results:
Sending build context to Docker daemon 249.3 kB Step 1/5 : FROM node:7.7.2-alpine ---> 95b4a6de40c3 Step 2/5 : WORKDIR /usr/app ---> e215b737ca38 Removing intermediate container 3b0bb16a8721 Step 3/5 : COPY package.json . ---> 930082a35f18 Removing intermediate container ac3ab0693f61 Step 4/5 : RUN npm install --quiet ---> Running in 46a7dcbba114 ### NPM MODULES INSTALLED ### ---> 525f662aeacf ---> dd46e9316b4d Removing intermediate container 46a7dcbba114 Step 5/5 : COPY . . ---> 1493455bcf6b Removing intermediate container 6d75df0498f9 Successfully built 1493455bcf6b
You have now successfully created the application image using Docker. Currently, however, our app won’t do much since we still need a database, and we want to connect everything together. This is where Docker Compose will help us out.
Now that you know how to create an image with a
Dockerfile, let’s create an application as a service and connect it to a database. Then we can run some setup commands and be on our way to creating that new todo list.
Create the file
/> touch docker-compose.yml
The Docker Compose file will define and run the containers based on a configuration file. We are using compose file version 2https://docs.docker.com/compose/compose-file/compose-file-v2/ syntax, and you can read up on it on Docker’s site.
An important concept to understand is that Docker Compose spans “buildtime” and “runtime.” Up until now, we have been building images using
docker build ., which is “buildtime.” This is when our containers are actually built. We can think of “runtime” as what happens once our containers are built and being used.
Compose triggers “buildtime” — instructing our images and containers to build — but it also populates data used at “runtime,” such as env vars and volumes. This is important to be clear on. For instance, when we add things like volumes and command, they will override the same things that may have been set up via the Dockerfile at “buildtime.”
docker-compose.yml file in your editor and copy/paste the following lines:
version: '2' services: web: build: . command: npm run dev volumes: - .:/usr/app/ - /usr/app/node_modules ports: - "3000:3000" depends_on: - postgres environment: DATABASE_URL: postgres://todoapp@postgres/todos postgres: image: postgres:9.6.2-alpine environment: POSTGRES_USER: todoapp POSTGRES_DB: todos
This will take a bit to unpack, but let’s break it down by service.
The first directive in the web service is to
build the image based on our
Dockerfile. This will recreate the image we used before, but it will now be named according to the project we are in,
nodejsexpresstodoapp. After that, we are giving the service some specific instructions on how it should operate:
command: npm run dev – Once the image is built, and the container is running, the
npm run dev command will start the application.
volumes: – This section will mount paths between the host and the container.
.:/usr/app/ – This will mount the root directory to our working directory in the container.
/usr/app/node_modules – This will mount the
node_modules directory to the host machine using the buildtime directory.
environment: – The application itself expects the environment variable
DATABASE_URL to run. This is set in
ports: – This will publish the container’s port, in this case
3000, to the host as port
DATABASE_URL is the connection string.
postgres://todoapp@postgres/todos connects using the
todoapp user, on the host
postgres, using the database
Like the NodeJS image we used, the Docker Store has a prebuilt image for PostgreSQL. Instead of using a
build directive, we can use the name of the image, and Docker will grab that image for us and use it. In this case, we are using
postgres:9.6.2-alpine. We could leave it like that, but it has
environmentvariables to let us customize it a bit.
environment: – This particular image accepts a couple environment variables so we can customize things to our needs.
POSTGRES_USER: todoapp – This creates the user
todoapp as the default user for PostgreSQL.
POSTGRES_DB: todos – This will create the default database as todos.
Now that we have our services defined, we can build the application using
docker-compose up. This will show the images being built and eventually starting. After the initial build, you will see the names of the containers being created:
Pulling postgres (postgres:9.6.2-alpine)... 9.6.2-alpine: Pulling from library/postgres 627beaf3eaaf: Pull complete e351d01eba53: Pull complete cbc11f1629f1: Pull complete 2931b310bc1e: Pull complete 2996796a1321: Pull complete ebdf8bbd1a35: Pull complete 47255f8e1bca: Pull complete 4945582dcf7d: Pull complete 92139846ff88: Pull complete Digest: sha256:7f3a59bc91a4c80c9a3ff0430ec012f7ce82f906ab0a2d7176fcbbf24ea9f893 Status: Downloaded newer image for postgres:9.6.2-alpine Building web ... Creating nodejsexpresstodoapp_postgres_1 Creating nodejsexpresstodoapp_web_1 ... web_1 | Your app is running on port 3000
At this point, the application is running, and you will see log output in the console. You can also run the services as a background process, using
docker-compose up -d. During development, I prefer to run without
-d and create a second terminal window to run other commands. If you want to run it as a background process and view the logs, you can run
At a new command prompt, you can run
docker-compose ps to view your running containers. You should see something like the following:
Name Command State Ports ------------------------------------------------------------------------------------------------ nodejsexpresstodoapp_postgres_1 docker-entrypoint.sh postgres Up 5432/tcp nodejsexpresstodoapp_web_1 npm run dev Up 0.0.0.0:3000->3000/tcp
This will tell you the name of the services, the command used to start it, its current state, and the ports. Notice
nodejsexpresstodoapp_web_1 has listed the port as
0.0.0.0:3000->3000/tcp. This tells us that you can access the application using
localhost:3000/todos on the host machine.
/> curl localhost:3000/todos 
package.json file has a script to automatically build the code and migrate the schema to PostgreSQL. The schema and all of the data in the container will persist as long as the
postgres:9.6.2-alpine image is not removed.
Eventually, however, it would be good to check how your app will build with a clean setup. You can run
docker-compose down, which will clear things that are built and let you see what is happening with a fresh start.
Feel free to check out the source code, play around a bit, and see how things go for you.
The application itself includes some integration tests built using
jest. There are various ways to go about testing, including creating something like
docker-compose.test.ymlfiles specific for the test environment. That’s a bit beyond the current scope of this article, but I want to show you how to run the tests using the current setup.
The current containers are running using the project name
nodejsexpresstodoapp. This is a default from the directory name. If we attempt to run commands, it will use the same project, and containers will restart. This is what we don’t want.
Instead, we will use a different project name to run the application, isolating the tests into their own environment. Since containers are ephemeral (short-lived), running your tests in a separate set of containers makes certain that your app is behaving exactly as it should in a clean environment.
In your terminal, run the following command:
/> docker-compose -p tests run -p 3000 --rm web npm run watch-tests
You should see
jest run through integration tests and wait for changes.
docker-compose command accepts several options, followed by a command. In this case, you are using
-p tests to run the services under the
tests project name. The command being used is
run, which will execute a one-time command against a service.
docker-compose.yml file specifies a port, we use -
p 3000 to create a random port to prevent port collision. The
--rmoption will remove the containers when we stop the containers. Finally, we are running in the web service
npm run watch-tests.
Thanks for reading !
Looking to build dynamic, extensively featured, and full-fledged web applications?
Hire NodeJs Developer to create a real-time, faster, and scalable application to accelerate your business. At HourlyDeveloper.io, we have a team of expert Node.JS developers, who have experience in working with Bootstrap, HTML5, & CSS, and also hold the knowledge of the most advanced frameworks and platforms.
Contact our experts: https://bit.ly/3hUdppS
#hire nodejs developer #nodejs developer #nodejs development company #nodejs development services #nodejs development #nodejs
AppClues Infotech is one of the leading NodeJS app development company in USA that offering excellent NodeJS development services for web app development. We provide customized and high-quality NodeJS app development services to clients for different industries with advanced technology and functionalities.
Why Choose AppClues Infotech for NodeJS Application Development?
• Fast App Development
• Real-Time Application
• Single Codebase
• Lower Cost
• Built-in NPM Support
• Inexpensive Testing and Hosting
#top nodejs app development company in usa #nodejs web app development #nodejs development agency in usa #hire nodejs app developers in usa #custom nodejs app development company #best nodejs app development service company
We at ByteCipher have expert and skilled NodeJS developers dedicated to offer you a full spectrum of NodeJS app development services. ByteCipher is a well established NodeJS development company in USA & India and having solid experience in building dynamic and high data-driven apps with this light-weighted tool named Node.JS. For more information visit us at https://bit.ly/3eNewaZ
#nodejs development company in usa #nodejs web development company #nodejs developers india #top node js web development company india #node js development company in india #web-development
With more of us using smartphones, the popularity of mobile applications has exploded. In the digital era, the number of people looking for products and services online is growing rapidly. Smartphone owners look for mobile applications that give them quick access to companies’ products and services. As a result, mobile apps provide customers with a lot of benefits in just one device.
Likewise, companies use mobile apps to increase customer loyalty and improve their services. Mobile Developers are in high demand as companies use apps not only to create brand awareness but also to gather information. For that reason, mobile apps are used as tools to collect valuable data from customers to help companies improve their offer.
There are many types of mobile applications, each with its own advantages. For example, native apps perform better, while web apps don’t need to be customized for the platform or operating system (OS). Likewise, hybrid apps provide users with comfortable user experience. However, you may be wondering how long it takes to develop an app.
To give you an idea of how long the app development process takes, here’s a short guide.
_Average time spent: two to five weeks _
This is the initial stage and a crucial step in setting the project in the right direction. In this stage, you brainstorm ideas and select the best one. Apart from that, you’ll need to do some research to see if your idea is viable. Remember that coming up with an idea is easy; the hard part is to make it a reality.
All your ideas may seem viable, but you still have to run some tests to keep it as real as possible. For that reason, when Web Developers are building a web app, they analyze the available ideas to see which one is the best match for the targeted audience.
Targeting the right audience is crucial when you are developing an app. It saves time when shaping the app in the right direction as you have a clear set of objectives. Likewise, analyzing how the app affects the market is essential. During the research process, App Developers must gather information about potential competitors and threats. This helps the app owners develop strategies to tackle difficulties that come up after the launch.
The research process can take several weeks, but it determines how successful your app can be. For that reason, you must take your time to know all the weaknesses and strengths of the competitors, possible app strategies, and targeted audience.
The outcomes of this stage are app prototypes and the minimum feasible product.
#android app #frontend #ios app #minimum viable product (mvp) #mobile app development #web development #android app development #app development #app development for ios and android #app development process #ios and android app development #ios app development #stages in app development
For a developer, becoming a team leader can be a trap or open up opportunities for creating software. Two years ago, when I was a developer, I was thinking, “I want to be a team leader. It’s so cool, he’s in charge of everything and gets more money. It’s the next step after a senior.” Back then, no one could tell me how wrong I was. I had to find it out myself.
I’m naturally very organized. Whatever I do, I try to put things in order, create systems and processes. So I’ve always been inclined to take on more responsibilities than just coding. My first startup job, let’s call it T, was complete chaos in terms of development processes.
Now I probably wouldn’t work in a place like that, but at the time, I enjoyed the vibe. Just imagine it — numerous clients and a team leader who set tasks to the developers in person (and often privately). We would often miss deadlines and had to work late. Once, my boss called and asked me to come back to work at 8 p.m. to finish one feature — all because the deadline was “the next morning.” But at T, we were a family.
We also did everything ourselves — or at least tried to. I’ll never forget how I had to install Ubuntu on a rack server that we got from one of our investors. When I would turn it on, it sounded like a helicopter taking off!
At T, I became a CTO and managed a team of 10 people. So it was my first experience as a team leader.
Then I came to work at D — as a developer. And it was so different in every way when it came to processes.
They employed classic Scrum with sprints, burndown charts, demos, story points, planning, and backlog grooming. I was amazed by the quality of processes, but at first, I was just coding and minding my own business. Then I became friends with the Scrum master. I would ask him lots of questions, and he would willingly answer them and recommend good books.
My favorite was Scrum and XP from the Trenches by Henrik Kniberg. The process at D was based on its methods. As a result, both managers and sellers knew when to expect the result.
Then I joined Skyeng, also as a developer. Unlike my other jobs, it excels at continuous integration with features shipped every day. Within my team, we used a Kanban-like method.
We were also lucky to have our team leader, Petya. At our F2F meetings, we could discuss anything, from missing deadlines to setting up a task tracker. Sometimes I would just give feedback or he would give me advice.
That’s how Petya got to know I’d had some management experience at T and learned Scrum at D.
So one day, he offered me to host a stand-up.
#software-development #developer #dev-team-leadership #agile-software-development #web-development #mobile-app-development #ios-development #android-development