{"@attributes":{"version":"2.0"},"channel":{"title":"DEV Community: Francis Sunday","description":"The latest articles on DEV Community by Francis Sunday (@codehakase).","link":"https:\/\/dev.to\/codehakase","image":{"url":"https:\/\/media2.dev.to\/dynamic\/image\/width=90,height=90,fit=cover,gravity=auto,format=auto\/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F26692%2F51245c26-62f1-4723-b342-c61209b818b2.jpeg","title":"DEV Community: Francis Sunday","link":"https:\/\/dev.to\/codehakase"},"language":"en","item":[{"title":"Building Small Containers for Kubernetes","pubDate":"Sun, 02 Dec 2018 20:06:40 +0000","link":"https:\/\/dev.to\/codehakase\/building-small-containers-for-kubernetes-290j","guid":"https:\/\/dev.to\/codehakase\/building-small-containers-for-kubernetes-290j","description":"
\n

This is a cross post. Original post can be found on my Blog<\/a><\/p>\n<\/blockquote>\n\n

The first step to deploying any app to Kubernetes<\/a>, is to bundle the app in a container. There are several official, and community-backed container images for various languages and distros, and most of these containers can be really large, or sometimes contain overheads your app may never need\/use.<\/p>\n\n

Thanks to Docker<\/a>, you can easily create container images in a few steps; specify a base image, add your app-specific changes, and build your container.
\n<\/p>\n\n

\n
FROM<\/span> golang:alpine<\/span>\n\nWORKDIR<\/span> \/app<\/span>\n\nADD<\/span> . \/app<\/span>\n\nEXPOSE<\/span> 8080<\/span>\n\nENTRYPOINT<\/span> [\"\/app\/run\"]<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
We specified a base image (Linux alpine in this case), set the working directory to be used in the container, exposed a network port, and an entry point, which will start the app in the container. With the Dockerfile set, we can build the container.
\n<\/p>\n\n
\n
$ <\/span>docker build myapp .<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
While the above process is pretty straight forward, there are some issues to put into consideration. Using the default images can lead to large container images, security vulnerabilities, and memory overheads.<\/p>\n\n
\n  \n  \n  Let's flesh out a sample app\n<\/h4>\n\n
We'll write a simple app in Go, that exposes a single HTTP route that returns a string when hit. We will build a Docker image from it.
\n<\/p>\n\n
\n
package<\/span> main<\/span>\n\nimport<\/span> (<\/span>\n    \"fmt\"<\/span>\n    \"log\"<\/span>\n    \"net\/http\"<\/span>\n    \"time\"<\/span>\n)<\/span>\n\nfunc<\/span> main<\/span>()<\/span> {<\/span>\n    r<\/span> :=<\/span> http<\/span>.<\/span>NewServeMux<\/span>()<\/span>\n    r<\/span>.<\/span>HandleFunc<\/span>(<\/span>\"\/api\/\"<\/span>,<\/span> func<\/span>(<\/span>w<\/span> http<\/span>.<\/span>ResponseWriter<\/span>,<\/span> r<\/span> *<\/span>http<\/span>.<\/span>Request<\/span>)<\/span> {<\/span>\n        fmt<\/span>.<\/span>Fprintf<\/span>(<\/span>w<\/span>,<\/span> \"Hello From Go!\"<\/span>)<\/span>\n    })<\/span>\n    s<\/span> :=<\/span> &<\/span>http<\/span>.<\/span>Server<\/span>{<\/span>\n        Addr<\/span>:<\/span>        \":8080\"<\/span>,<\/span>\n        Handler<\/span>:<\/span>     r<\/span>,<\/span>\n        ReadTimeout<\/span>:<\/span> 10<\/span> *<\/span> time<\/span>.<\/span>Second<\/span>,<\/span>\n    }<\/span>\n    fmt<\/span>.<\/span>Println<\/span>(<\/span>\"Starting server on port 8080\"<\/span>)<\/span>\n    log<\/span>.<\/span>Fatal<\/span>(<\/span>s<\/span>.<\/span>ListenAndServe<\/span>())<\/span>\n}<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
Let's build the Docker image with our app. First, we need to create a Dockerfile.
\n<\/p>\n\n
\n
FROM<\/span> golang:latest<\/span>\n\nRUN <\/span>mkdir<\/span> \/app\nADD<\/span> . \/app\/<\/span>\nWORKDIR<\/span> \/app<\/span>\nRUN <\/span>go build -o<\/span> myapp .\n\nCMD<\/span> [\"\/app\/myapp\"]<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
Build the image.<\/p>\n\n
\n
PS: Replace tag with anything of choice: \/appname
\n<\/p>\n<\/blockquote>\n\n
\n
$ <\/span>docker build -t<\/span> codehakase\/goapp .<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
That's it! We just Dockerized a simple Go app. Let's take a look at the image we
\njust built.
\n\"docker<\/a><\/p>\n\n
For a simple Go app, the image is over 700 megabytes. The Go binary itself is
\nprobably a few megabytes in size, and the additional overhead is wasted space,
\nand can also be a hiding place for bugs and security vulnerabilities.<\/p>\n\n
What is taking up so much space? In this scenario, the container needs Go
\ninstalled, along with all the dependencies Go relies on, and all of this sits on
\ntop of a Debian or Linux distro.<\/p>\n\n
There are two ways to reduce container image sizes, actually three of which the
\nthird is more often used in the Go community:<\/p>\n\n
    \n
  1. Using Small Base Images<\/li>\n
  2. The Builder Pattern<\/li>\n
  3. Using Empty Images<\/li>\n<\/ol>\n\n
    Using small base images are the easiest way to reduce container image size. The
    \nstack\/language in use probably provides an official image that's much smaller
    \nthan the default image.<\/p>\n\n
    Let's update the Dockerfile to use a small base image. We're going to use
    \ngolang:alpine<\/code> in this case.
    \n<\/p>\n\n
    \n
    FROM<\/span> golang:alpine<\/span>\n\nRUN <\/span>mkdir<\/span> \/app\nADD<\/span> . \/app\/<\/span>\nWORKDIR<\/span> \/app<\/span>\nRUN <\/span>go build -o<\/span> myapp .\n\nCMD<\/span> [\"\/app\/myapp\"]<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
    Rebuild image.
    \n<\/p>\n\n
    \n
    $ <\/span>docker build -t<\/span> codehakase\/goapp .<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
    With the update to the Dockerfile, our image is now smaller compared to the
    \nprevious image.
    \n    \"using<\/a><\/p>\n\n
    This image size if still quite large, and we can even go smaller using the
    \nBuilder Pattern. Since we're using a compiled language (Go) in this example, in
    \nthe builder pattern, we should note that compiled languages often requires tools
    \nthat are not necessarily needed to run the code. These tools are mostly for
    \nbuilding and compiling to a binary. With the builder pattern, we can remove
    \nthese tools in the final container.<\/p>\n\n
    To use the Builder pattern in our existing example, we'll compile our code in a
    \ncontainer, and then use the compiled code to package the final container, without
    \nall the required tools.
    \n<\/p>\n\n
    \n
    FROM<\/span> <\/span>golang:alpine<\/span> <\/span>AS<\/span> <\/span>main-env<\/span>\nRUN <\/span>mkdir<\/span> \/app\nADD<\/span> . \/app\/<\/span>\nWORKDIR<\/span> \/app<\/span>\nRUN <\/span>cd<\/span> \/app &&<\/span> go build -o<\/span> myapp\n\nFROM<\/span> alpine<\/span>\nWORKDIR<\/span> \/app<\/span>\nCOPY<\/span> --from=main-env \/app\/myapp \/app<\/span>\nEXPOSE<\/span> 8080<\/span>\n\nENTRYPOINT<\/span> .\/myapp<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
    We updated the Dockerfile to use the builder pattern. First, it builds and
    \ncompiles the app in the alpine<\/code> container and name the step main-env<\/code>, and
    \nthen copies the binary from the previous step to the new container.<\/p>\n\n
    Rebuild the multistage Dockerfile.
    \n<\/p>\n\n
    \n
    $ <\/span>docker build -t<\/span> codehakase\/goapp .<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
    Remember the first image we built that was over 700 megabytes? We've been able
    \nto cut that down to 10.7 megabytes using the builder pattern.<\/p>\n\n
    We can still reduce this number a bit, by making use of scratch (empty)
    \nimages. What's a scratch image? It's a special docker image that's empty. To use
    \nthis, we need to first build our app outside the docker environment and add the
    \ncompiled binary to the container.
    \n<\/p>\n\n
    \n
    $ <\/span>go build -o<\/span> myapp .<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
    We'll update the Dockerfile to add the binary to a scratch image.
    \n<\/p>\n\n
    \n
    FROM<\/span> scratch<\/span>\nADD<\/span> myapp \/<\/span>\nCMD<\/span> [\"\/myapp\"]<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
    We got it down to 6.5 megabytes, cool! Let's try running our container to test
    \nour app.
    \n<\/p>\n\n
    \n
    $ <\/span>docker run -it<\/span> codehakase\/goapp\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
    You may get an error like this:
    \n    <\/a><\/p>\n\n
    Reason for this error, is the Go binary is looking for libraries on the OS its
    \nrunning on, since the scratch image is empty, there are no libraries to look in.
    \nWe need to modify the build command to statically compile our Go app:
    \n<\/p>\n\n
    \n
    $ GO_ENABLED<\/span>=<\/span>0 GOOS<\/span>=<\/span>linux go build -a<\/span> -installsuffix<\/span> cgo -o<\/span> myapp .<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
    Rebuild with docker build -t codehakase\/goapp<\/code>, and run the our container
    \nagain, forwarding the port on the container to our machine:
    \n<\/p>\n\n
    \n
    $ <\/span>docker run -it<\/span> -p<\/span> 8080:8080 codehakase\/goapp\n  Starting server on port 8080\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
    Navigate to http:\/\/localhost:8080\/api<\/code> to test the response from the app.<\/p>\n\n
    \n  \n  \n  Conclusion\n<\/h3>\n\n
    The goal of this article was to explain how to reduce container sizes
    \nspecifically for Go apps. With smaller containers, you have more performance, as
    \nbuilding your containers say in a CI environment is going to be faster, pushing
    \nyour built images to a container registry will take less amount of time, and
    \nmost importantly pulling these containers to your distributed kubernetes
    \nclusters will be faster, as smaller containers are less likely to delay a
    \ndeployment for a new cluster.<\/p>\n\n
    If you have any suggestions or comments, leave a comment below or ping
    \n    @codehakase<\/a><\/p>\n\n","category":["kubernetes","go","docker","webdev"]},{"title":"Live coding streams recommendations?","pubDate":"Tue, 18 Sep 2018 15:11:27 +0000","link":"https:\/\/dev.to\/codehakase\/live-coding-streams-recommendations-31o9","guid":"https:\/\/dev.to\/codehakase\/live-coding-streams-recommendations-31o9","description":"
    Hello!<\/p>\n\n
    I've been searching, and following up with some live coding streams on youtube and twitch, specifically targeted towards backend engineering and devops. I'd like to get your recommendations so I check them out also.<\/p>\n\n
    Thanks!<\/p>\n\n","category":["discuss","livecoding","backend","devops"]},{"title":"Explain Meta Programming Like I'm Five","pubDate":"Sat, 21 Apr 2018 17:40:13 +0000","link":"https:\/\/dev.to\/codehakase\/explain-meta-programming-like-im-five-j6c","guid":"https:\/\/dev.to\/codehakase\/explain-meta-programming-like-im-five-j6c","description":"
    What it is, it's benefits, where it comes to play.<\/p>\n\n","category":"explainlikeimfive"},{"title":"Building a Web App With Go, Gin and React","pubDate":"Sat, 21 Apr 2018 16:44:48 +0000","link":"https:\/\/dev.to\/codehakase\/building-a-web-app-with-go-gin-and-react-5ke","guid":"https:\/\/dev.to\/codehakase\/building-a-web-app-with-go-gin-and-react-5ke","description":"
    \n
    This article was originally posted on My Blog<\/a><\/p>\n<\/blockquote>\n\n
    TL;DR:<\/strong> In this tutorial, I'll show you how easy it is to build a web application with Go and the Gin framework and add authentication to it. Check out the Github repo<\/a> for the code we're going to write.<\/p>\n\n\n\n\n
    Gin<\/strong> is a high-performance micro-framework that delivers a very minimalistic framework that carries with it only the most essential features, libraries, and functionalities needed to build web applications and microservices. It makes it simple to build a request handling pipeline from modular, reusable pieces. It does this by allowing you to write middleware that can be plugged into one or more request handlers or groups of request handlers.<\/p>\n\n
    \n  \n  \n  Gin Features\n<\/h2>\n\n
    Gin is a fast, simple yet fully featured and very efficient web framework for Go. Check out some of the features below that makes it a worthy framework to consider for your next Golang project.<\/p>\n\n
    Let's build this image and see how large it turns out.
    \n    \"scratch<\/a><\/p>\n\n
    The result of the build is a new container which is just a little over 10
    \nmegabytes.
    \n    \"builder<\/a><\/p>\n\n