The course is part of this learning path
Build and Packaging
Test and Validation
This training course is designed to help you master the skills of designing and building cloud native applications.
Observe first hand the end-to-end process of building a sample cloud native application using React, Go, MongoDB, and Docker. By taking this course you'll not only get to see firsthand the skills required to create a robust enterprise grade cloud native application, but you'll also be able to apply them yourself as all code and deployment assets are available for you to perform your own deployment:
What you'll learn:
- Understand the basic principles of building cloud native applications
- Understand the benefits of using React for frontend web development
- Understand the benefits of using Go for backend api development
- Understand the benefits of using MongoDB as a database system
- And finally, you’ll learn how to package and run microservices as lightweight containers using Docker
This training course provides you with several hands on demonstrations where you will observe first hand how to
- Build a React based web frontend
- Build a Go based API
- Deploy and configure a MongoDB database
- Deploy the full end-to-end application to Docker running locally
- A basic understanding of web based software development
- Previous exposure to containers and containerisation - in particular docker
- Anyone interested in learning how to architect cloud native applications
- Anyone interested in using modern development tools such as React, Go, MongoDB and Docker
- Anyone interested in containerisation
- DevOps Practitioners
- [Instructor] Okay, welcome back. In this lecture, I'll demonstrate how to compile and package the API into a lightweight, deployable micro service, using Docker.
Starting off in the Demo directory, I'll clone the API repository into it like so. I'll then navigate into the new vote-app API Go directory, and list its contents. Let's now take a closer look at both the go.mod and the go.sun files. These files declare all of the third party packages that the API depends on. To be able to perform a Go compilation, we first need to download a local copy of these. Let's clear the terminal and now run the following Go get command to download all of the required dependencies. Go, get, dash v for verbose.
Excellent, Go has downloaded and installed our dependencies, but, exactly where? Let's go and find them. I'll next run the command go env for environment to display all of the Go environment variables, like so. The Go path, which is now highlighted is where we need to go and take a look at. We can do so by running the following command: cd, opening back tick, go, env, GOPATH, closing back tick. If we query the current directory path, we can see that we have indeed been swapped in to the directory tracked by the go path variable.
If we now list the contents of the current directory, we can see the standard Go directories, bin, package and source. If we then navigate into the package modules directory, like so, then we'll start to see where our downloaded dependencies have been saved to. Okay, I'll now jump back into the API project group directory, like so. Right, we're now ready to compile our API. Before we do, I'll display the contents of the current directory. Notice the absence of an API file. Let's now create this file by performing a Go compilation, over our source code. I'll run the command, Go Build, dash O for output, API, which is the name of the Binary. Now that was quick, this is one of the benefits of Go. Quick compilation. If we relist out the contents of the current directory, we can now see the new API binary created by the previous command. This API binary has been compiled for the current operating system. Therefore, it should be executable. Let's try it. I'll clear the terminal and then execute the API like so.
As you can see, the API has launched fine, and is now attempting to connect to the backend mongo DB database. Using the default connection string, which is not valid for our local environment, we're not worried about this now. Let's kill the API process and move on. Since we're going to be running the API binary with an A container, we actually need to recompile it for the Linux operating system that the container will be based on. Therefore, we need to recompile it explicitly for the Linux operating system, like so. This instructs the compiler to create a binary that will be executable on Linux running on an AMD 64 Architecture.
Okay, again the compilation has been successful, and the API executable has now been recreated. This time if we try to run it locally, it will fail, since my Mac doesn't understand the binary format. At this stage, we are ready to build the API docker image. Let's again clear the terminal and then display the contents of the docker file located in the project route, like so. What should stick out about this docker file, as with the previous docker file, is its simplicity. We are deriving from the alpine image, a very compact Linux based operating system. We then copy across, the single API binary, and run it up, exposing it on port 8080. Okay, now for the magic. Let's build and tag the API docker image like so. Again, if we examine the local docker images, we now see the new version one API docker image, another great result.
This completes the build and packaging phase for the API micro service component and has put us in good shape to progress to achieving our end-to-end cloud in aid of application, running locally.
About the Author
Jeremy is the DevOps Content Lead at Cloud Academy where he specializes in developing technical training documentation for DevOps.
He has a strong background in software engineering, and has been coding with various languages, frameworks, and systems for the past 20+ years. In recent times, Jeremy has been focused on DevOps, Cloud, Security, and Machine Learning.
Jeremy holds professional certifications for both the AWS and GCP cloud platforms.