Introduction to Kubernetes: How to Deploy a Node.js Docker App

While container technology has existed for years, Docker really took it mainstream. A lot of companies and developers now use containers to ship their apps. Docker provides an easy to use interface to work with containers.
However, for any non-trivial application, you will not be deploying “one container", but rather a group of containers on multiple hosts. In this article, we’ll take a look at Kubernetes, an open-source system for automating deployment, scaling, and management of containerized applications.

Prerequisites: This article assumes some familiarity with Docker. If you need a refresher, check out Understanding Docker, Containers and Safer Software Delivery.

What Problem Does Kubernetes Solve?
With Docker, you have simple commands like docker run or docker stop to start/stop a container respectively. Unlike these simple commands that let you do operations on a single container, there is no docker deploy command to push new images to a group of hosts.
Many tools have appeared in recent times to solve this problem of "container orchestration"; popular ones being Mesos, Docker Swarm (now part of the Docker engine), Nomad, and Kubernetes. All of them come with their pros and cons but, arguably, Kubernetes has the most mileage at this point.
Kubernetes (also referred to as ‘k8s’) provides powerful abstractions that completely decouple application operations such as deployments and scaling from underlying infrastructure operations. So, with Kubernetes, you do not work with individual hosts or virtual machines on which to run you code, but rather Kubernetes sees the underlying infrastructure as a sea of compute on which to put containers.
Kubernetes Concepts
Kubernetes has a client/server architecture. Kubernetes server runs on your cluster (a group of hosts) on which you will deploy your application. And you typically interact with the cluster using a client, such as the kubectl CLI.
A pod is the basic unit that Kubernetes deals with, a group of containers. If there are two or more containers that always need to work together, and should be on the same machine, make them a pod. A pod is a useful abstraction and there was even a proposal to make them a first class docker object.
A node is a physical or virtual machine, running Kubernetes, onto which pods can be scheduled.
A label is a key/value pair that is used to identify a resource. You could label all your pods serving production traffic with "role=production", for example.
Selections let you search/filter resources by labels. Following on from the previous example, to get all production pods your selector would be "role=production".
A service defines a set of pods (typically selected by a "selector") and a means by which to access them, such as single stable IP address and corresponding DNS name.
Deploy a Node.js App on GKE using Kubernetes
Now, that we are aware of basic Kubernetes concepts, let’s see it in action by deploying a Node.js application on Google Container Engine (referred to as GKE). You’ll need a Google Cloud Platform account for the same (Google provides a free trial with $300 credit).
1. Install Google Cloud SDK and Kubernetes Client
kubectl is the command line interface for running commands against Kubernetes clusters. You can install it as a part of Google Cloud SDK. After Google Cloud SDK installs, run the following command to install kubectl:
$ gcloud components install kubectl

or brew install kubectl if you are on Mac. To verify the installation run kubectl version.
You’ll also need to setup the Google cloud SDK with credentials for your Google cloud account. Just run gcloud init and follow the instructions.
2. Create a GCP project
All Google Cloud Platform resources are created under a project, so create one from the web UI.
Set the default project ID while working with CLI by running:
gcloud config set project {PROJECT_ID}

3. Create a Docker Image of your application
Here is the application that we’ll be working with: express-hello-world. You can see in the Dockerfile that we are using an existing Node.js image from dockerhub. Now, we’ll build our application image by running:
$ docker build -t hello-world-image .

Run the app locally by running:
docker run –name hello-world -p 3000:3000 hello-world-image

If you visit localhost:3000 you should get the response.
4. Create a cluster
Now we’ll create a cluster with three instances (virtual machines), on which we’ll deploy our application. You can do it from the fairly intuitive web UI by going to container engine page or by running this command:
Continue reading %Introduction to Kubernetes: How to Deploy a Node.js Docker App%


Web Push Notifications

Push notifications have readily been available for mobile platforms for quite some time. But push notifications for the web are still a new technology that isn’t supported widely yet. At the time of writing this article, only Chrome, Firefox, and Opera supported push notifications. Safari has support for push notifications through a propriety API that is beyond the scope of this article.

So let’s see how we can implement push notifications in the browsers that do support them.


Introduction to FuseBox — a Faster, Simpler Webpack Alternative

Webpack has arguably become the de facto JavaScript module bundler, but it has a reputation for being confusing and difficult to learn. In this article I want to present a faster, simpler Webpack alternative — FuseBox. FuseBox is a next generation ecosystem of tools that provides for all of the requirements of the development lifecycle. […]
Continue reading %Introduction to FuseBox — a Faster, Simpler Webpack Alternative%


Node.js 8: The First Week

This week, we got the release of Node.js 8 – an entirely new version of Node.js, heading toward becoming an LTS release line in October. The release of Node.js 8 came with quite a few hefty new features, many small improvements, and tons of new opportunities for developers.
Because of just how massive Node.js 8 was – both the release itself and the community’s overwhelmingly positive response – I wanted to share some of the highlights from the first week of Node.js 8.


Two-Factor Authentication with Node.js

There are a variety of strategies for protecting your important online credentials.  We often hear about password managers and generators, but for me, the more important strategy is using two-factor authentication (2FA).  Passwords can be guessed, phone numbers can be spoofed, but using two-factor authentication essentially requires that user be in possession of a physical device with an app like Google Authenticator, […]
The post Two-Factor Authentication with Node.js appeared first on David Walsh Blog.


How I Designed & Built a Fullstack JavaScript Trello Clone

A few weeks ago, I came across a developer sharing one of his side projects on GitHub: a Trello clone. Built with React, Redux, Express, and MongoDB, the project seemed to have plenty of scope for working on fullstack JS skills.
I asked the developer, Moustapha Diouf, if he’d be interested in writing about his process for choosing, designing, and building the project and happily, he agreed. I hope you’ll find it as interesting as I did, and that it inspires you to work on ambitious projects of your own!
Nilson Jacques, Editor

In this article, I’ll walk you through the approach I take, combined with a couple of guidelines that I use to build web applications. The beauty of these techniques is that they can be applied to any programming language. I personally use them at work on a Java/JavaScript stack and it has made me very productive.
Before moving on to the approach, I’ll take some time to discuss how:

I defined my goals before starting the project.
I decided on the tech stack to use.
I setup the app.

Keep in mind that since the entire project is on GitHub (madClones), I’ll focus on design and architecture rather than actual code. You can check out a live demo of the current code: you can log in with the credentials Test/Test.

If you’re interested in taking your JavaScript skills to the next level, sign up for SitePoint Premium and check out our latest book, Modern JavaScript

Defining the Goals
I started by taking a couple of hours a day to think about my goals and what I wanted to achieve by building an app. A to-do list was out of the question, because it was not complex enough. I wanted to dedicate myself to at least 4 months of serious work (it’s been 8 months now). After a week of thinking, I came up with the idea to clone applications that I like to use on a daily basis. That is how the Trello clone became a side project.
In summary, I wanted to:

Build a full stack JavaScript application. Come out of my comfort zone and use a different server technology.
Increase my ability to architect, design, develop, deploy and maintain an application from scratch.
Practice TDD (test driven development) and BDD (behavior driven development). TDD is a software practice that requires the developer to write test, watch them fail, then write the minimum code to make the test pass and refactor (red, green, refactor). BDD, on the other hand, puts an emphasis on developing with features and scenario. Its main goal is to be closer to the business and write a language they can easily understand.
Learn the latest and the hottest frameworks. At my job, I use angular 1.4 and node 0.10.32 (which is very sad I know) so I needed to be close to the hot stuff.
Write code that follows the principle of the 3R’s: readability, refactorability, and reusability.
Have fun. This is the most important one. I wanted to have fun and experiment a lot since I was (and still am) the one in charge of the project.

Choosing the Stack
I wanted to build a Node.js server with Express and use a Mongo database. Every view needed to be represented by a document so that one request could get all the necessary data. The main battle was for the front-end tech choice because I was hesitating a lot between Angular and React.
I am very picky when it comes to choosing a framework because only testability, debuggability and scalability really matter to me. Unfortunately, discovering if a framework is scalable only comes with practice and experience.
I started with two proof-of-concepts (POCs): one in Angular 2 and another one in React. Whether you consider one as a library and the other one as a framework doesn’t matter, the end goal is the same: build an app. It’s not a matter of what they are, but what they do. I had a huge preference for React, so I decided to move forward with it.
Getting Started
I start by creating a main folder for the app named TrelloClone. Then I create a server folder that will contain my Express app. For the React app, I bootstrap it with Create React App.
I use the structure below on the client and on the server so that I do not get lost between apps. Having folders with the same responsibility helps me get what I am looking for faster:

src: code to make the app work
src/config: everything related to configuration (database, URLs, application)
src/utils: utility modules that help me do specific tasks. A middleware for example
test: configuration that I only want when testing
src/static: contains images for example
index.js: entry point of the app

Setting up the Client
I use create-react-app since it automates a lot of configuration out of the box. “Everything is preconfigured and hidden so that you can focus on code", says the repo.
Here is how I structure the app:

A view/component is represented by a folder.
Components used to build that view live inside the component folder.
Routes define the different route options the user has when he/she is on the view.
Modules (ducks structure) are functionalities of my view and/or components.

Setting up the Server
Here is how I structure the app with a folder per domain represented by:

Routes based on the HTTP request
A validation middleware that tests request params
A controller that receives a request and returns a result at the end

If I have a lot of business logic, I will add a service file. I do not try to predict anything, I just adapt to my app’s evolution.
Choosing Dependencies
When choosing dependencies I am only concerned by what I will gain by adding them: if it doesn’t add much value, then I skip. Starting with a POC is usually safe because it helps you "fail fast".
If you work in an agile development you might know the process and you might also dislike it. The point here is that the faster you fail, the faster you iterate and the faster you produce something that works in a predictable way. It is a loop between feedback and failure until success.
Here is a list of dependencies that I always install on any React app:
Continue reading %How I Designed & Built a Fullstack JavaScript Trello Clone%


Getting Started With VS Code for Node.js Development

As developers, there’s one type of tool that we all use to express our intents into a language that systems can interpret and act on: the text editor.
Text editors can be as in-depth or as simple as you want them to be. I personally use VS Code to write both code and prose. I’ve personally tweaked VS Code to be streamlined to my taste for writing apps in Node.js and wanted to share some of the Node.js tooling (outside of N|Solid and Certified Modules) that I use.


Installing Node.js 8 on Linux via Package Manager

At NodeSource, we maintain the consistently-updated Node.js repositories for Linux distributions. These aren’t repositories like most Node.js developers think of them – git repositories – but rather repositories in the sense of installing Node.js via the given Linux OS’s built-in package manager – like apt and yum.
With the release of Node.js 8 recently, we’ve gone ahead and built the Node.js 8 binaries and made them readily available if you’re using Node.js on a Debian- or Enterprise Linux-based distro.


Moving From Node.js to .NET With Raygun and Javascript Jabber [Podcast]

In this podcast, the CEO and co-founder of Raygun John-Daniel Trask talks to Chuck Wood – host of the JavaScript Jabber podcast.
They are joined by Aimee Knight and Joe Eames. In this episode, Chuck and John-Daniel discuss how (and why) Raygun migrated to .NET from Node.js, plus some interesting and little-known facts about frontend frameworks.