bruno-krebs

I am passionate about developing highly scalable, resilient applications. I love everything from the database, to microservices (Kubernetes, Docker, etc), to the frontend. I find amazing to think about how all pieces work together to provide a fast and pleasurable experience to end users, mainly because they have no clue how complex that "simple" app is.

R&D Content Architect

Bruno Krebs

Learn about the basic Kubernetes concepts while deploying a sample application on a real cluster.

Kubernetes Tutorial - Step by Step Introduction to Basic Concepts

jorge-fatta

Jorge is a Software Engineer that enjoys building tools for colleagues. He manages the Developer Tools team at Auth0. This team works on improving development workflow through tools and automation. He likes to spend time with family, playing football, or preparing and drinking all possible forms of coffee.

Engineering Manager

Jorge Fatta

Helping engineers stay focused on building features that solve the hard problems of identity for customers.



Auth0 is continuously growing. To share a couple of examples, we just hit a new milestone: [_2.5B+ monthly logins securely authenticated_](https://twitter.com/auth0/status/1101216297206059009) and we [_ended 2018 with a nearly 80 percent increase in both sales and new customers_](https://auth0.com/blog/auth0-closes-year-of-impressive-growth-in-2018/).


We are growing and scaling the organization at a really fast pace, and engineering is no exception. This presents some interesting and fun challenges:

1. Promoting and developing the **culture** that fuels this endeavor.
2. **Hiring** and retaining great engineers.
3. Minimizing duplicate work and time to be **productive** as new people come in.

This blog post is focused on how Auth0 is addressing part of that last challenge; by building a dedicated team to unleash the potential in Auth0 developers to deliver business value with confidence.

## Developer Tools Team at Auth0

In the same way that Auth0's goal is to make identity simple for developers, the Developer Tools team goal is to let our engineers fully focus on development and providing value for our customers. We want to provide the best tools to keep our developers happy and engaged shipping new features instead of struggling every day with exhausting and repetitive tasks that could be automated.

We defined the mindset we want to adopt to develop our tools and outlined a roadmap with the following vision:

> Provide toolchains that Auth0 engineering teams can use to improve their workflow, automate manual tasks, simplify complex processes, and implement a set of company-wide standards.

### What we do

1. Work closely with the engineering teams to understand their pain points, provide tools and guidance.
2. Investigate existing tools and develop new ones to solve their needs:

    * Development Environment tools.
    * Change Management tools.
    * Debugging and Performance tools.
    * Incident Response tools.
    * Work with the [_SRE team_](https://auth0.com/blog/progressive-service-architecture-at-auth0/) to integrate site reliability tools into the platform.

1. Recommended patterns & practices:

    * Identify patterns currently in use across our organization.
    * Provide developer tools for Scaffolding and Code Snippets.
    * Promote the adoption and tooling for the best engineering practices, e.g.: [_contract testing_](https://martinfowler.com/bliki/ContractTest.html).

### What we don’t do

1. While we provide general guidance, we don’t do consultancy, i.e.: we neither do work at a particular team's requests to tackle specific issues, provide advice on demand, or do an investigation by request nor develop customized solutions to solve a specific team's needs.
2. We don’t provide advice or work on particular issues on demand: our tools are developed following a *product* approach.
3. We don’t embed team members on another team to build tooling. We might do it for discovery, but development happens within the Development Tools team.
4. We don’t debug and profile internal services, we provide the toolchain for that.
5. We don’t do [_SRE (Site Reliability Engineering)_](https://auth0.com/blog/progressive-service-architecture-at-auth0/), we might provide tooling that could improve the experience during their analysis.
6. We don’t investigate a random tool or technology on demand. We do it if it is related to reducing developer pain.

<include src="TweetQuote" quoteText="Learn how our engineers stay focused on solving the hard problems of identity for our customers."/>

## Tools Development Mindset

We are approaching the development of the tools as internal **products**, guided by these principles:

1. **Ownership**: We own the tools that we ship, following a “*You Build It, You Run It*” principle.

    * We operate what we build: taking care of the CI/CD, incident response, etc.
    * We take care of not just the coding but also keeping the *product* running in good shape.

1. **Extensibility**: We develop these tools taking extensibility into account from scratch.

    * For example, any engineer should be able to easily extend* *the* CLI *that we provide to interact with Auth0’s local development environment.

1. **Internal Collaboration**: We engage our users to **contribute** with the tool evolution, collecting their feedback and welcoming their contributions to the code and documentation (via pull requests on git repositories).

We aim to follow an **iterative** process to develop our tools (just like our Product Engineering teams), working closely with our internal customers.


> The process adopted by our team suits the lean startup cycle model.

->![Jeff Patton & Associates: lean startup cycle model](https://images.ctfassets.net/23aumh6u8s0i/4TRZnZXwjpgNp5gtf4u168/b8ab189eea4a634cdbadfcf67b5c12be/lean-startup-model)<-

*[*_Lean Startup Model_*](https://www.jpattonassociates.com/common-agile-int-for-startups/lean-startup-model/)* by *[*_Jeff Patton_*](https://www.jpattonassociates.com/) is licensed under [CC BY 2.0](https://creativecommons.org/licenses/by/2.0/).*

<include src="TweetQuote" quoteText="The Auth0 Developer Tools team shares three key principles to develop a tools-development mindset that helped them create successful internal products for developers."/>

## Our Tools

Some of the tools that we currently maintain and regularly work on had a great impact and adoption rates within the organization but were built prior to adopting the _internal dev tools as product_ mindset mentioned above. It was originally hard for us to *learn *from the tools once released without any kind of usage metrics. For that reason, we focused on existing solutions by:

* Improving **documentation**, both user guides and internal playbooks concisely describing deployment, troubleshooting, and **contribution** guidelines.
* Instrumenting **usage and performance** metrics to **measure** the impact of our iterative improvements.

### Vivaldi

->![Containers on a dock](https://images.ctfassets.net/23aumh6u8s0i/5d1b2HI9Jjwld4HEksBQff/ec3bdb6bf8883d78cf39f907bb6f65bf/containers-on-a-dock)<-

*Photo by *[*_Guillaume Bolduc_*](https://unsplash.com/photos/uBe2mknURG4)* on *[*_Unsplash_*](https://unsplash.com/)*.*


**Vivaldi** is the tool on which we have invested most of our efforts so far. Named after the Italian musical composer, it is a [_Docker_](https://www.docker.com/) container-based development environment that allows engineers to run a local Auth0 on their machine.
Through a command line interface (CLI), Vivaldi provides commands to quickly interact with our service instances running locally in order to:

* Update dependencies.
* Run tests.
* Attach a debugger.
* Run diagnosis tools.
* Execute performance profilers.

->![Vivaldi: Docker container-based development environment](https://images.ctfassets.net/23aumh6u8s0i/1NlLXfq8I0vpBm5KL3cI5l/30cd621072a76bcd0406151786f49246/vivaldi)<-

The initial version of the tool had a **great impact on the development cycle** and was **widely adopted**. Before *Vivaldi*, developers needed to manually spin up the services they were working on, fighting with dependencies with their local environment. Now they can rely on an isolated and replicable environment, being able to spin up the entire services cluster relatively quickly.

As our teams and number of services grow, we are now actively working with teams to better implement a fast development loop without relying too much on running all Auth0 services locally. We are already planning the next generation of Vivaldi, which will support future growth in a scalable way.

### Slack Bots

->![Droid giving you a helping hand](https://images.ctfassets.net/23aumh6u8s0i/H5W70I4X8Ot6NSsj0VHyv/fadc300cf5495e31413a4ef43f2128d7/droid-giving-you-a-helping-hand)<-

*Photo by *[*_Franck V._*](https://unsplash.com/photos/jIBMSMs4_kA)* on *[*_Unsplash_*](https://unsplash.com/)*.*

We developed an internal Slack bot platform called _Gynoid_ during a hackathon and it was quickly adopted by our engineering organization. The platform is customized to satisfy the needs of our developers:

* To build Slack bots easily: just create a JavaScript file, add metadata, and you are done!.
* To install Slack bots straight from a GitHub repository.
* To extend existing bots from different sources: one bot, multiple functions, different repositories.
    * We call these extensions Droids. To install new extensions, we have a Gynoid that serves as a wrapper for this library. Our _Gynoid Droid_ is responsible for registering and extending our bots directly from Slack.

A notable Droid is one that serves as a _concierge_ for any Slack channel, properly named @concierge. It works like this:

* A channel that needs a person on duty to address direct questions invites `@concierge` to the channel.

->![Inviting the concierge Slack bot to a channel](https://images.ctfassets.net/23aumh6u8s0i/762YoyCbXhOlyM9zQAr24/469fe557035293e641012aa2bc03c672/invite-concierge-slack-bot)<-

* A teammate is assigned the role of `@concierge`.

->![Assigning the concierge role to a teammate](https://images.ctfassets.net/23aumh6u8s0i/2u1bJjRFdCbJWf48k9t1Ot/3fb1c5c67e6d6819df21f09564896e18/assign-concierge-slack-bot)<-


* When someone needs to ask anything to a team, for example, they visit the team's channel and ask the question directly to `@concierge`.

->![Asking a question to Slack bot concierge](https://images.ctfassets.net/23aumh6u8s0i/3Gtm4wdoomqbMJas4rzjGf/a1249a2842972eae97cc08b29328a28d/asking-question-concierge)<-

* The teammate with the role of `@concierge` is sent a direct message through Slackbot with the concierge request.

->![Slack bot concierge sending a direct message to teammate](https://images.ctfassets.net/23aumh6u8s0i/4nPgWa3KasUha1YjLcAmos/641263ac54adb338d5906ee7d410673b/concierge-slack-bot-direct-message)<-

* The concierge has now the responsibility to research and to address the request directly. If the request is outside of the scope of the team, the request is redirected to the appropriate channel

The concierge droid helps us avoid unnecessary noise in Slack &mdash; especially since it is widely used within our company as a good substitute for `@here` and `@channel` when asking questions. It's very useful when you have an "on-call" rotation in your team and people need to reach the teammate on call through a Slack channel.

## Roadmap

We are currently working on the next major version of our main tools, focusing on:

* **Scalability improvements**: Vivaldi, our Docker-based development environment, will run an increasing number of services without compromising the developer machine resources.
* **Robustness**: Gynoid, our slack bots platform, will have end-to-end tests and its dependencies will be upgraded to the latest stable versions, allowing our team and contributors from other teams to introduce changes or develop new *droids* with confidence.

Additionally, we’re in the early stages (discovery, viability analysis, and ideation) for a **unified internal CLI** (command-line interface): we already have multiple CLIs that provide different types of functionality. As the number of CLIs keeps growing, it will become hard to keep track of them.

Some teams will decide to use a different tech stack, which may require different runtime dependencies and a distinct CLI to better manage it. However, we could create a unified CLI, customizable and extensible to meet the needs of different tech stacks. Having a unified CLI will help internal toolchains scale while staying maintainable.

## Conclusion

We aim to provide an optimal developer experience, unified across the engineering organization. To do this we take ownership of the toolchains, iterate to improve them and encourage teams to use these tools that have already proven their value on making developers more productive.

We dedicate our Developer Tools team efforts to the discovery, building, maintenance, and promotion of reusable solutions so that the rest of the engineers don’t have to struggle with repetitive tasks, walk through slow development cycles, or constantly switch contexts to take care of maintenance tasks that can be automated.

We want Auth0 engineers to be focused on building new features that solve the hard problems of identity for our customers.

<include src="asides/AboutAuth0" />


Auth0 Internal Dev Tools: Unleashing Engineering Potential

332d7898dae6bc56031ac3507a0248ba

I'm a full-stack developer with a passion for technology and code. I love writing tutorials for developers to showcase a particular technology whilst building something useful at the same time. Right now  I can mostly be found developing for the front-end, playing around with Docker, or tinkering with Unreal Engine and electronics!

Developer Experience Engineer

Steve Hobbs

Learn how to transform your Windows 10 machine into a Linux powerhouse.



Imagine for a moment that you're stranded on a desert island. You're a software developer and have been using Linux systems or an Apple Mac ever since you were old enough to type on a keyboard. Yet the only things that you were able to bring with you to your desert island was a Windows machine, and enough tea and biscuits to last a lifetime. Luckily the island already has an internet connection — what do you do?

Okay, you _could_ just [download Ubuntu](https://www.ubuntu.com/#download) and install it onto a Virtual Machine, but there is another way. Which as it happens, also involves installing Ubuntu...

## <a class="toc-target" id="a-week-without-my-macbook"></a>A Week Without My Macbook

I was in a very similar situation recently, although instead of being stranded on a desert island I was forced to leave my MacBook with the Apple Store while they fixed a [weird issue with my touch bar](http://www.youtube.com/watch?v=bvU1FIJ0daU).

I had to find a way to keep working while my development machine was in the shop. I love using a Unix command line and tools such as [ZSH](http://www.zsh.org/) and [Oh-my-zsh!](https://ohmyz.sh/). In my day job, I have to use [Ruby](https://www.ruby-lang.org/en/) and [Node](https://nodejs.org/en/) on a regular basis, and I love using [iTerm2](https://www.iterm2.com/) as my main terminal emulator. I also primarily use desktop tools like [Visual Studio Code](https://code.visualstudio.com/), [Docker](https://www.docker.com/products/docker-desktop), and [Slack](https://slack.com/).

One option would be to simply install Docker and [set up a containerized development environment](https://auth0.com/blog/use-docker-to-create-a-node-development-environment/), but that would be _too easy_.

Could I continue using my normal development tools and my workflow without my MacBook? I set out to find out!

<include src="TweetQuote" quoteText="Learn how to install Windows Subsystem for Linux, turning your Windows 10 machine into a full-blown Linux powerhouse"/>

## <a class="toc-target" id="cross-platform-applications"></a>Cross-Platform Applications

Of course, a lot of the applications I just mentioned are available cross-platform, with many of them being HTML, CSS, and JavaScript applications wrapped up using [Electron](https://electronjs.org/). This covers apps like Visual Studio Code and Slack, which are the two main tools I use day-to-day.

I occasionally dip into using [Intellij](https://www.jetbrains.com/idea/) for [Scala development](https://auth0.com/blog/build-and-secure-a-scala-play-framework-api/) and again this runs cross-platform. So it looks like all the desktop applications I need are available, which is great!

For my main development and blog writing activities, I primarily use [Git](https://git-scm.com/), [Ruby](https://www.ruby-lang.org/en/) and [NodeJS](https://nodejs.org/en/). Fortunately, there are Windows installers for all of these that ultimately work, but they all feel a bit _Windows-y_. For example, the best way to use Git on Windows is to use [Git for Windows](https://gitforwindows.org/), which provides a Git Bash application that drops you into a terminal running Git. Or you can use a desktop application like [GitHub Desktop](https://git-scm.com/), or the built-in Git interface inside Visual Studio Code.

![Windows desktop running Visual Studio Code, GitHub Desktop and WSL](https://images.ctfassets.net/23aumh6u8s0i/7RERJuU7VNzU0C4YEr1c8/2bd1e3c69604cb4f7a61b026e149b10a/working-on-windows_desktop-01)

As for Ruby, I enjoy using [RVM](https://rvm.io/), which makes the installation and management of different Ruby versions very easy and relatively painless. Windows is supported using something like [Cygwin](https://cygwin.com/), but again it's not really a native solution and I ran into issues getting it to work the way I'm used to.

All of these are good solutions (if you can get them working) but seeing as the goal of this exercise is to figure out a way to work just like I have been doing on my MacBook, I wanted to explore further.

## <a class="toc-target" id="terminal-velocity"></a>Terminal Velocity

I really enjoy using the terminal for the speed and ability to get things done concisely and quickly. Using a terminal that supports features such as tabs, horizontal and vertical splitting, and Unix command utilities and features like piping and output redirection is very important to me.

Unfortunately, this is where Windows starts to break down. Windows has Command Prompt, which doesn't support any of those nice UI features that I like, and with me not being familiar with Windows shell script, I find it cumbersome. There is also Powershell and, as the name suggests, is very powerful but it's something new I'd have to learn. Ultimately, it would take time until I'm as productive as before. Interestingly for the Powershell users, [posh-git](https://github.com/dahlbyk/posh-git) gives you adornments in the terminal as the Git status of the current folder, which is one of the features I like about Oh-my-zsh.

![Screenshot of posh-git with Powershell on Windows](https://images.ctfassets.net/23aumh6u8s0i/5onDW4obFAGbOnqIhzlD05/256515dafffb5900bc9d9f2b674f2ad4/working-on-windows_posh-git)

I'm in love with [iTerm2](https://www.iterm2.com/) on the Mac for its ability to use tabs, split windows, profiles, and theming, so is there anything that gets me close?

[Hyper](https://hyper.is/) is a terminal emulator that supports at least the UI features of being able to use tabs and window splitting. It's based on Electron and so is cross-platform, and supports more advanced features like [themes](https://hyper.is/themes) and [plugins](https://hyper.is/plugins). I do like theming my applications so that they look more pleasing to the eye, but I was willing to forget about that for this short-lived exercise.

However, it's just an emulator and therefore is still just using Windows shell script. Something more fundamental under the hood would have to change.

## <a class="toc-target" id="enter-the-windows-subsystem-for-linux"></a>Enter the Windows Subsystem for Linux

[Windows Subsystem for Linux](https://docs.microsoft.com/en-us/windows/wsl/about) (WSL) is a way to run native Linux commands and tools alongside your existing Windows apps. It doesn't use a virtual machine and is as easy to access as opening a terminal window. To quote directly from the documentation:

> The Windows Subsystem for Linux lets developers run GNU/Linux environment -- including most command-line tools, utilities, and applications -- directly on Windows, unmodified, without the overhead of a virtual machine.

Sounds good, doesn't it? In theory, I should be able to use all the command-line tools that I'm used to without leaving my Windows desktop environment.

To install WSL, you need to be on the Windows 10 Fall Creator's Update (build 16215). Then, you can install the feature by using the "Turn Windows features on or off" facility and ticking "Windows Subsystem for Linux":

![Screenshot of the Add Windows Features dialog](https://images.ctfassets.net/23aumh6u8s0i/4RFI6W9FLq7l2eZps2IeIH/1effca5d6fb069c6941631d38128e9d5/working-on-windows_installing-wsl)

It can also be installed by running this Powershell command:

```powershell
# Run this inside Powershell to enable the WSL feature
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux
```

> **Note**: The machine may need to be restarted once WSL is installed

One of the many [Linux distributions on the Windows Store](https://www.microsoft.com/en-gb/search/shop/apps?q=linux&devicetype=pc&Price=0) can then be installed as a Windows App. I chose [Ubuntu](https://www.microsoft.com/en-gb/p/ubuntu-1804-lts/9n9tngvndl3q?activetab=pivot:overviewtab) as it's the one I'm most familiar with. An Ubuntu app becomes available once it's installed, but the normal Windows Command Prompt app can be used in its place if you so wish.

Then, to enter a Linux terminal, open Command Prompt (or your terminal emulator of choice) and type `wsl` to get started. The next thing you will see is your Linux command prompt.

```bash
# My WSL command prompt inside the Command Prompt application
/c/Users/steve >
```

So what can be done from here? Supposedly anything that can normally be done from an Ubuntu terminal. Let's check what release of Ubuntu I'm using:

```bash
> lsb_release -a

No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.2 LTS
Release:        18.04
Codename:       bionic
```

Use `curl`?

```bash
> curl -i google.com

HTTP/1.1 301 Moved Permanently
Location: http://www.google.com/
Content-Type: text/html; charset=UTF-8
Date: Tue, 26 Feb 2019 10:42:51 GMT
Expires: Thu, 28 Mar 2019 10:42:51 GMT
Cache-Control: public, max-age=2592000
Server: gws
Content-Length: 219
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN

```

Install Vim?

```bash
> sudo apt-get install vim

Reading package lists... Done
Building dependency tree
Reading state information... Done
The following package was automatically installed and is no longer required:
  libfreetype6
Use 'sudo apt autoremove' to remove it.
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 3 not upgraded.
Need to get 1152 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu bionic/main amd64 vim amd64 2:8.0.1453-1ubuntu1 [1152 kB]
Fetched 1152 kB in 0s (2468 kB/s)
(Reading database ... 39405 files and directories currently installed.)
Preparing to unpack .../vim_2%3a8.0.1453-1ubuntu1_amd64.deb ...
Unpacking vim (2:8.0.1453-1ubuntu1) over (2:8.0.1453-1ubuntu1) ...
Setting up vim (2:8.0.1453-1ubuntu1) ...
```

As you can see, `apt-get` is available and can be used to install any software that would normally be available on a native instance of Ubuntu.

Can something like NVM be installed the same way as on a native Linux distribution?

> For the purposes of this recording and in the interest of time, I had already installed NVM on this machine, but not Node itself. Take a look and see what happens!

<AmpContent>
<amp-video controls
  layout="responsive"
  width="480" height="270">
  <source src="https://cdn.auth0.com/blog/working-on-windows:nvm-video.mp4"
    type="video/webm" />
</amp-video>

</AmpContent>

<NonAmpContent>

<video controls="controls">
  <source src="https://cdn.auth0.com/blog/working-on-windows:nvm-video.mp4">
   Your browser doesn't support HTML5 video. Here is a link to the <a href="https://cdn.auth0.com/blog/working-on-windows:nvm-video.mp4"> working on Windows nvm video</a> instead.
</video>

</NonAmpContent>

Thankfully, nothing unremarkable happens! I get Node 10 and NPM installed just as happily as I would have done on a native Ubuntu install. I can also confirm that I was able to install RVM perfectly well, by following [the installation instructions](https://rvm.io/) that I would have normally followed on Linux.

Furthermore, I was able to install ZSH and Oh-my-zsh without any issues, again using the instructions provided for Linux. With this in place, I'm already most of the way towards working the way I'm used to on my Macbook!

## <a class="toc-target" id="developers-developers-developers"></a>Developers, Developers, Developers

Now that I have the tools installed, what is the actual development experience like?

I can happily report that it is fairly unintrusive to the point where I almost forget I'm working on a Windows machine. Thanks to the fact that Windows drives are automatically mounted into your Linux environment, I still get access to my files and folders from within my Ubuntu environment. This means I can use Git and all the other command-line utilities that I'm used to, but still manipulate those files using whatever editor on the host Windows machine I want. By default, your host drives are available in the `/mnt` folder. So a Windows path of `D:\Development\auth0` would be available in your Linux environment as `/mnt/d/Development/auth0`.

At the moment, it's not possible to get access to the Linux filesystem from the Windows host, but [that will change in Windows 10 build 1903](https://blogs.msdn.microsoft.com/commandline/2019/02/15/whats-new-for-wsl-in-windows-10-version-1903/). In a nutshell, WSL will start a <a href="https://en.wikipedia.org/wiki/9P_(protocol)">9P file server</a> on bootup with Windows as the client, serving Linux files over an internal network protocol.

### Windows UI features

For me, the operating system shell is just as part a part of the development experience as the software I use to do my job. For example, I'm a heavy user of OSX's [Spotlight](https://support.apple.com/en-gb/HT204014) feature, and I regularly navigate through my operating system simply by using text search; it's very easy to press `Cmd+Space` and search for what I want.

Windows 10 supports just the same functionality and allows me to move around the operating system very easily, opening programs and manipulating windows simply by using the keyboard. Pressing `Windows Key` opens the Windows Start Menu, where I can just start typing what I want. Admittedly this is not obvious, as there is no focussed text box to indicate to the user that they're able to type a search term.

<AmpContent>
<amp-video controls
  layout="responsive"
  width="480" height="270">
  <source src="https://cdn.auth0.com/blog/working-on-windows:startmenu-video.mp4"
    type="video/webm" />
</amp-video>

</AmpContent>

<NonAmpContent>

<video controls="controls">
  <source src="https://cdn.auth0.com/blog/working-on-windows:startmenu-video.mp4">
   Your browser doesn't support HTML5 video. Here is a link to the <a href="https://cdn.auth0.com/blog/working-on-windows:startmenu-video.mp4"> working on Windows start video</a> instead.
</video>

</NonAmpContent>

Another feature of OSX that I often use is [multiple desktops](https://support.apple.com/en-gb/HT204100), or _Spaces_. This is part of the Mission Control feature that can partition applications into different Spaces, allowing you to easily swipe between them. I use this feature to organize my work better. As an example, with every instance of Visual Studio Code that I have open, I tend to have a corresponding instance of iTerm2 open at my working directory for the project I'm working on. Using multiple desktops, I can group these instances together so that I have different desktops set up for different projects. I can switch between different desktops using a trackpad gesture, or by using `Ctrl+Left/Right Arrow` to move between them.

Luckily for me, Windows 10 supports this exact feature! Just like on OSX, different desktops can be created that play host to different instances of running applications, and I can switch between them using simple keyboard commands. Pressing `Win Key+Tab` gives me a Mission Control-like overview of my available desktops and applications. I can even specify that an instance of an app is available across _all_ my desktops (it's handy to have my favorite music player available wherever I need it!).

![Screenshot of Windows' multiple desktops feature](https://images.ctfassets.net/23aumh6u8s0i/27p5Ty1oNdHUndxZFICkn/f843763eb99f42a17ab07e104773c3dd/working-on-windows_multi-desktops)

<include src="TweetQuote" quoteText="With WSL, I love that I have all the command-line tools that I'm used to available to me, as well as the ability to use multiple desktops, search, and use all my favorite desktop applications."/>

### A word about Docker

I wanted to touch on my experience using Docker with this setup. I already have [Docker Desktop](https://www.docker.com/products/docker-desktop) installed on my host Windows machine, and I was concerned that I may have had to uninstall that in order to get it working inside WSL. Either that, or I would have to live with having _two_ instances of Docker on my machine taking up valuable hard-drive space; one for the Windows host, and another inside WSL.

Thankfully, I didn't have to do either of those things and following [these instructions on setting Docker up](https://nickjanetakis.com/blog/setting-up-docker-for-windows-and-wsl-to-work-flawlessly) to work on WSL (flawlessly, as the article title puts it) was very easy and painless. The basic principle is that Docker running on the Windows host can also be used by the Docker client running inside WSL, as the two are interfaced by a REST API. The key piece of configuration is to tell the Docker client inside WSL where the host is. By default, it connects to a Docker instance running on the same machine, but in this case, we can point it to the instance running on the Windows host.

After having gone through the setup myself, I can confirm that Docker from inside WSL works as expected!

### SSH keys

As you might expect from reading through this post, generating SSH keys works exactly the same way as on any other Linux distro. I followed the [SSH key guide on GitHub.com](https://help.github.com/en/enterprise/2.14/user/articles/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent) and it just works. The caveat is that the SSH key will be generated for your WSL install, and so the key will need to be added to any services you use that require SSH keys.

This is fine for me, but if you already have an SSH key for your Windows profile then you can [symlink your `.ssh` folder into your WSL install](https://florianbrinkmann.com/en/3436/ssh-key-and-the-windows-subsystem-for-linux/) if you wish to use the same keys.

## <a class="toc-target" id="ive-now-sold-my-macbook"></a>I've Now Sold My Macbook!

I haven't actually sold my Macbook. However, given everything that I've experienced getting my development environment _pretty close_ to what I'm used to, I'm pretty certain that I would be able to live without it for a while longer. I love that I have all the command-line tools that I'm used to available to me, as well as the ability to use multiple desktops, search, and use all my favorite desktop applications.

So far I haven't found an instance where Windows Subsystem for Linux has provided an obstacle where I can't get working, although I admit that even the use-case I present here is probably quite simplistic compared to how some other people would like to use it.

Are you a WSL user? Have your experiences been good or bad? Tell us about it in the comments below!

<include src="asides/AboutAuth0" />


Convert Windows PC to Linux (Ubuntu)

37590801?s=460&v=4

A software engineer who dreams about non-electric sheep and autonomous vehicles and likes to champion security.

Software Engineer

Dan Arias

Leverage Docker images and containers to create an isolated Node development environment that runs a server


In this tutorial, instead of creating and running a Node app locally, you'll to take advantage of the Debian Linux operating system that official Docker Node images are based on. You'll create a portable Node development environment that solves the **"But it runs on my machine"** problem that constantly trolls developers since containers are created predictably from the execution of Docker images on any platform.

Throughout this tutorial, you'll be working in two realms:

- **Local Operating System**: Using a CLI application, such as Terminal or PowerShell, you'll use a local installation of Docker to build images and run them as containers.

- **Container Operating System**: Using Docker commands, you'll access the base operating system of a running container. Within that context, you'll use a container shell to issue commands to create and run a Node app.

The container operating system runs in isolation from the local operating system. Any files created within the container won't be accessible locally. Any servers running within the container can't listen to requests made from a local web browser. **This is not ideal for local development**. To overcome these limitations, you'll bridge these two systems by doing the following:

- **Mount a local folder to the container filesystem**: Using this mount point as your container working directory, you'll persist locally any files created within the container and you'll make the container aware of any local changes made to project files.

- **Allow the host to interact with the container network**: By mapping a local port to a container port, any HTTP requests made to the local port will be redirected by Docker to the container port.

To see this Docker-based Node development strategy in action, you'll create a basic Node Express web server. Let's get started!

## <a class="toc-target" id="removing-the-burden-of-installing-node"></a>Removing the Burden of Installing Node

To run a simple "Hello World!" Node app, the typical tutorial asks to:

- Download and install Node
- Download and install Yarn
- To use different versions of Node, uninstall Node and install [`nvm`](https://github.com/creationix/nvm)
- Install NPM packages globally

![Ain't nobody got time for that!](https://images.ctfassets.net/23aumh6u8s0i/4xVUHMWNLagUIrrnQDuE46/24abba17c53d63744bfb84e235796432/Aint-Nobody-Got-Time)

Each operating system has its own quirks making the aforementioned installations non-standard. However, access to the Node ecosystem can be standardized using Docker images. **The only installation requirement for this tutorial is Docker**. If you need to install Docker, choose your operating system from [this Docker installation document](https://docs.docker.com/install/#supported-platforms) and follow the steps provided.

Similar to how NPM works, Docker gives us access to a large registry of Docker images called [Docker Hub](https://hub.docker.com/). From Docker Hub, you can pull and run different versions of Node as images. You can then run these images as local processes that don't overlap or conflict with each other. You can simultaneously create a cross-platform project that depends on Node 8 with NPM and another one that depends on Node 11 with Yarn.

## <a class="toc-target" id="creating-the-project-foundation"></a>Creating the Project Foundation

To start, anywhere in your system, create a `node-docker` folder. This is the project directory.

With the goal of running a Node Express server, under the `node-docker` project directory, create a `server.js` file, populate it as follows and save it:

```javascript
// server.js
const express = require("express");
const app = express();

const PORT = process.env.PORT || 8080;

app.get("/", (req, res) => {
  res.send(`
    <h1>Docker + Node</h1>
    <span>A match made in the cloud</span>
  `);
});

app.listen(PORT, () => {
  console.log(`Server listening on port ${PORT}...`);
});
```

A Node project needs a `package.json` file and a `node_modules` folder. _Assuming that Node is not installed in your system_, you'll use Docker to create those files following a structured workflow.

## <a class="toc-target" id="accessing-the-container-operating-system"></a>Accessing the Container Operating System

You can gain access to the container OS with any of the following methods:

- <a href="#single-command" target="_self">Using a single but long `docker run` command</a>.
- <a href="#dockerfile" target="_self">Using a `Dockerfile` combined with a short `docker run` command</a>.
- <a href="#docker-compose" target="_self">Using a `Dockerfile` in combination with Docker Compose</a>.

### <a id="single-command"></a> Using a single `docker run` command

Execute the following command:

```
docker run --rm -it --name node-docker \
-v $PWD:/home/app -w /home/app \
-e "PORT=3000" -p 8080:3000  \
-u node node:latest /bin/bash
```

Let's breakdown this `docker run` command to understand how helps you access the container shell:

```bash
docker run --rm -it
```

`docker run` creates a new container instance. The [`--rm` flag](https://docs.docker.com/engine/reference/run/#clean-up---rm) automatically stops and removes the container once the container exits. The combined `-i` and `-t` flags run [interactive processes such as a shell](https://docs.docker.com/engine/reference/run/#foreground). The `-i` flag keeps the STDIN (Standard Input) open while the `-t` flag lets the process pretend it is a text terminal and pass along signals.

> Think of `--rm` as "out of sight, out of mind".

> Without the `-it` team, you won't see anything on the screen.

![Hello, IT, have you tried turning it off and on again?](https://images.ctfassets.net/23aumh6u8s0i/3nakiU8KELbKSpyeyDXaPQ/b226e7664c58d45971fd708ee36c8117/giphy)

```
docker run --rm -it --name node-docker
```

The [`--name` flag](https://docs.docker.com/engine/reference/run/#name---name) assigns a friendly name to the container to easily identify it in logs and tables. For example when you run [`docker ps`](https://docs.docker.com/engine/reference/commandline/ps/).

```
docker run --rm -it --name node-docker \
-v $PWD:/home/app -w /home/app
```

The [`-v` flag](https://docs.docker.com/engine/reference/run/#volume-shared-filesystems) mounts a local folder into a container folder using this mapping as its argument:

`<HOST FOLDER RELATIVE PATH>:<CONTAINER FOLDER ABSOLUTE PATH>`

An environmental variable can print the current working directory when the command is executed: `$PWD` on Mac and Linux and `$CD` on Windows. The [`-w` flag](https://docs.docker.com/engine/reference/run/#workdir) sets the mounting point as the container working directory.

```
docker run --rm -it --name node-docker \
-v $PWD:/home/app -w /home/app \
-e "PORT=3000" -p 8080:3000
```

The [`-e` flag](https://docs.docker.com/engine/reference/run/#env-environment-variables) sets an environmental variable `PORT` with a value of `3000`. The [`-p` flag](https://docs.docker.com/engine/reference/run/#expose-incoming-ports) maps a local port `8080` to a container port `3000` to match the environmental variable `PORT` that is consumed within `server.js`:

```javascript
const PORT = process.env.PORT || 8080;
```

```
docker run --rm -it --name node-docker \
-v $PWD:/home/app -w /home/app \
-e "PORT=3000" -p 8080:3000  \
-u node node:latest /bin/bash
```

For security and to avoid file permission problems, the [`-u` flag](https://docs.docker.com/engine/reference/run/#user) sets the non-root user `node` available in the Node image as the user that runs the container processes. After setting the flags, the image to execute is specified: `node:latest`. The last argument is a command to execute inside the container once it's running. `/bin/bash` invokes the container shell.

> If the image is not present locally, Docker issues [`docker pull`](https://docs.docker.com/engine/reference/commandline/pull/) in the background to download it from [Docker Hub](https://hub.docker.com/).

Once the command executes, you'll see the container shell prompt:

```bash
node@<CONTAINER ID>:/home/app$
```

Before moving to the next method, exit the container terminal by typing `exit` and pressing `<ENTER>`.

### <a id="dockerfile"></a> Using a `Dockerfile`

The `docker run` command from the previous section is made of image build time and container runtime flags and elements: 

```
docker run --rm -it --name node-docker \
-v $PWD:/home/app -w /home/app \
-e "PORT=3000" -p 8080:3000  \
-u node node:latest /bin/bash
```

Anything related to image build time can be defined as a custom image using a `Dockerfile` as follows:

* `FROM` specifies the container base image: `node:latest`
* `WORKDIR` defines `-w`
* `USER` defines `-u`
* `ENV` defines `-e`
* `ENTRYPOINT` specifies to execute `/bin/bash` once the container runs

Based on this, under the `node-docker` project directory, create a file named `Dockerfile`, populate it as follows, and save it:

```dockerfile
FROM node:latest

WORKDIR /home/app
USER node
ENV PORT 3000

EXPOSE 3000

ENTRYPOINT /bin/bash
```

`EXPOSE 3000` documents the port to expose at runtime. However, container runtime flags that define container name, port mapping, and volume mounting still need to be specified with `docker run`.

The custom image defined within `Dockerfile` needs to be built using [`docker build`](https://docs.docker.com/engine/reference/commandline/build/) before it can be run. In your local terminal, execute:

```
docker build -t node-docker .
```

`docker build` provides your image the friendly name `node-docker` using the [`-t` flag](https://docs.docker.com/engine/reference/commandline/build/#tag-an-image--t). This is different than the container name. To verify that the image was created, run `docker images`.

With the image built, execute this shorter command to run the server:

```bash
docker run --rm -it --name node-docker \
-v $PWD:/home/app -p 8080:3000 \
node-docker
```

The container shell prompts comes up with the following format:

`node@<CONTAINER ID>:/home/app$`

Once again, before moving to the next method, exit the container terminal by typing `exit` and pressing `<ENTER>`.

### <a id="docker-compose"></a> Using Docker Compose

> For Linux, [Docker Compose is installed separately](https://docs.docker.com/compose/install/).

Based on the `Dockerfile` and the shorter `docker run` command of the previous section, you can create a Docker Compose YAML file to define your Node development environment as a service:

**`Dockerfile`**:

```dockerfile
FROM node:latest

WORKDIR /home/app
USER node
ENV PORT 3000

EXPOSE 3000

ENTRYPOINT /bin/bash
```

**Command**

```bash
docker run --rm -it --name node-docker \
-v $PWD:/home/app -p 8080:3000 \
node-docker
```

The only elements left to abstract from the `docker run` command are the container name, the volume mounting, and the port mapping.

Under the `node-docker` project directory, create a file named `docker-compose.yml`, populate it with the following content, and save it:

```yaml
version: "3"
services:
  nod_dev_env:
    build: .
    container_name: node-docker
    ports:
      - 8080:3000
    volumes:
      - ./:/home/app
```

* `nod_dev_env` gives the service a name to easily identify it
* `build` specifies the path to the `Dockerfile`
* `container_name` provides a friendly name to the container
* `ports` configures host-to-container port mapping
* `volumes` defines the mounting point of a local folder into a container folder

To start and run this service, execute the following command:

```
docker-compose up
```

`up` builds its own images and containers separate from those created by the `docker run` and `docker build` commands used before. To verify this run:

```bash
docker image
# Notice the image named <project-folder>_nod_dev_env
docker ps -a
# Notice the container named <project-folder>_nod_dev_env_<number>
```
 
`up` created an image and a container but the container shell prompt didn't come up. What happened? `up` starts the full service composition defined in `docker-compose.yml`. However, it doesn't present interactive output; instead, it only presents static service logs. To get interactive output, you use `docker-compose run` instead to run `nod_dev_env` individually. 

First, to clean the images and containers created by `up`, execute the following command in your local terminal:
       
```bash
docker-compose down
```

Then, execute the following command to run the service:

```bash
docker-compose run --rm --service-ports nod_dev_env
```

The `run` command acts like `docker run -it`; however, it doesn't map and expose any container ports to the host. In order to use the port mapping configured in the Docker Compose file, you use the `--service-ports` flag. The container shell prompt comes up once again with the following format:

`node@<CONTAINER ID>:/home/app$`

If for any reason the ports specified in the Docker Compose file are already in use, you can use the `--publish`, (`-p`) flag to manually specify a different port mapping. For example, the following command maps the host port `4000` to the container port `3000`:

```bash
docker-compose run --rm -p 4000:3000 nod_dev_env
```

## <a class="toc-target" id="installing-dependencies-and-running-the-server"></a>Installing Dependencies and Running the Server

> If you don't have an active container shell, using any of the previous section methods to access it.
 
In the container shell, initialize the Node project and install dependencies by issuing the following commands (if you prefer, use `npm`):

```bash
yarn init -y
yarn add express
yarn add -D nodemon
```

Verify that `package.json` and `node_modules` are now present under your local `node-docker` project directory.

[`nodemon`](https://github.com/remy/nodemon) streamlines your development workflow by restarting the server automatically anytime you make changes to source code. To configure `nodemon`, update `package.json` as follows:

```json
{
  // Other properties...
  "scripts": {
    "start": "nodemon server.js"
  }
}
```

In the container shell, execute `yarn start` to run the Node server.

To test the server, visit [`http://localhost:8080/`](http://localhost:8080/) in your local browser. Docker intelligently redirects the request from the host port `8080` to the container port `3000`.

To test the connection of local file content and server, open `server.js` locally, update the response as follows and save the changes:

```javascript
// server.js

// package and constant definitions...

app.get("/", (req, res) => {
  res.send(`
    <h1>Hello From Node Running Inside Docker</h1>
  `);
});

// server listening...
```

Refresh the browser window and observe the new response.

## <a class="toc-target" id="modifying-and-extending-the-project"></a>Modifying and Extending the Project


Assuming that Node is not installed in your local system, you can use the local terminal to modify project structure and file content but you can't issue any Node-related commands, such as `yarn add`. As the server runs within the container, you are also not able to make server requests to the internal container port `3000`.

In the event that you want to interact with the server within the container or modify the Node project, you need to execute commands against the running container using [`docker exec`](https://docs.docker.com/engine/reference/commandline/exec/) and the running container ID. You don't use `docker run` as that command would create a new isolated container.

Getting the running container ID is easy.

* If you already have a container shell open, the container ID is present in the shell prompt:

`node@<CONTAINER ID>:/home/app$`

* You can also get the container ID programmatically using [`docker ps`](https://docs.docker.com/engine/reference/commandline/ps/) to filter containers based on name and return the `CONTAINER ID` of any match:

```bash
docker ps -qf "name=node-docker"
```

> The `-f` flag filters containers by the `name=node-docker` condition. The `-q` (`--quiet`) limits the output to only display the ID of the match, effectively plugging the `CONTAINER ID` of `node-docker` into the `docker exec` command.

Once you have the container ID, you can use `docker exec` to:

* Open a new instance of the running container shell:

```bash
docker exec -it $(docker ps -qf "name=node-docker") /bin/bash
```

* Make a server request using the internal port `3000`:

```bash
docker exec -it $(docker ps -qf "name=node-docker") curl localhost:3000
```

* Install or remove dependencies:

```bash
docker exec -it $(docker ps -qf "name=node-docker") yarn add body-parser
```

> One you have another active container shell, you can easily run `curl` and `yarn add` there instead.

## <a class="toc-target" id="recap-and-uncovering-little-lies"></a>Recap... and Uncovering Little Lies

You've learned how to create an isolated Node development environment through different levels of complexity: by running a single `docker run` command, using a `Dockerfile` to build and run a custom image, and using Docker Compose to run a container as a Docker service.

Each level requires more file configuration but a shorter command to run the container. This is a worthy trade-off as encapsulating configuration in files makes the environment portable and easier to maintain. Additionally, you learned how to interact with a running container to extend your project.

You may still need to install Node locally for IDEs to provide syntax assistance, or you can use a CLI editor like `vim` within the container.

![Harry Potter is angry that he needs to download Node locally for his code editor to provide syntax assistance.](https://images.ctfassets.net/23aumh6u8s0i/fiXwLKWUXoYnHnCvlqgWL/735189d25b0f454bad861c84c67f50f2/giphy)

Even so, you can still benefit from this isolated development environment. If you restrict project setup, installation, and runtime steps to be executed within the container, you can standardize those steps for your team as everyone would be executing commands using the same version of Linux. Also, all the cache and hidden files created by Node tools stay within the container and don't pollute your local system. Oh, and you also get `yarn` for free!

[JetBrains](https://www.jetbrains.com/) is starting to offer the capability to use Docker images as remote interpreters for Node and Python when running and debugging applications. In the future, we may become entirely free from downloading and installing these tools directly in our systems. Stay tuned to see what the industry provides us to make our developer environments standard and portable.

<include src="asides/AboutAuth0" />


Use Docker to Create a Node Development Environment

Let's create some simple Node applications, and host them on our own DigitalOcean server using Dokku

Hosting Applications using DigitalOcean and Dokku

Let's learn how to properly handle exceptions on Spring Boot APIs while providing multi-language support (I18N) for the messages.

Exception Handling and I18N on Spring Boots APIs

Let's dockerize two instances of a Node.js application and load balance them with NGINX.



**TL;DR:** In this article we will see how easy it is to load balance *dockerized* Node.js applications with NGINX. We will create a simple Node.js application that serves an HTML file, containerize it with Docker, and containerize an NGINX instance that uses round-robin algorithm to load balance between two running instances of this application.

<include src="TweetQuote" quoteText="Check out how easy it is to load balance dockerized Node.js applications with NGINX."/>

## Docker and Containers

Docker is a software container platform. Developers use [Docker](https://www.docker.com/) to eliminate “works on my machine” problem when collaborating with co-workers. This is done by putting pieces of a software architecture on containers (a.k.a. *dockerize* or containerize).

Using containers, everything required to make a piece of software run is packaged into isolated containers. Unlike [Virtual Machines (VMs)](https://en.wikipedia.org/wiki/Virtual_machine), containers do not bundle a full operating system—only libraries and settings required to make the software work are needed. This makes them efficient, lightweight, self-contained and guarantees that software will always run on the same configuration, regardless of where it’s deployed.

To learn more about Docker, take a look at [this webinar](https://auth0.com/blog/docker-101-for-developers/).

## Installing Docker

Everything that we will need to test this architecture is Docker. As the instances of our [Node.js](https://nodejs.org/en/) application and [NGINX](https://www.nginx.com) will run inside Docker containers, we won't need to install them on our development machine. To install Docker, [simply follow the instructions on their website](https://www.docker.com/community-edition#/download).

## Creating the Node.js Application

To show NGINX load balancing in action, we are going to create a simple Node.js application that serves a static HTML file. After that, we are going to containerize this application and run it twice. Lastly, we will configure a *dockerized* NGINX instance to dispatch requests to both instances of our application.

In the end, we will be able to reach `http://localhost:8080` on our local machine to "randomly" get results from one or another instance. In fact, the result won't be randomly decided, we will configure NGINX to use round-robin algorithm to decide which instance will respond on each request.

But let's tackle one step at a time. To create this application we will first create a directory for the application, and then create an `index.js` file that will respond to HTTP requests.

To create the directory, let's issue the following command: `mkdir application`. After that, let's create the `index.js` file in this directory and paste the following source code:

```js
var http = require('http');
var fs = require('fs');

http.createServer(function (req, res) {
  res.writeHead(200, {'Content-Type': 'text/html'});
  res.end(`<h1>${process.env.MESSAGE}</h1>`);
}).listen(8080);
```

Everything that this Node.js script does is to answer HTTP requests to `http://localhost:8080` with and HTML tag that contains a message defined in the `MESSAGE` environment variable. To better understand how this works, we can run the following commands:

```bash
export MESSAGE=Howdy!
node index
```

And then open `http://localhost:8080` on a web browser. See? We got simple web page with the `Howdy!` message. Before proceeding, let's stop our application by hitting `Ctrl + C`.

## Dockerizing the Node.js Applications

To *dockerize* our Node.js application, we will need to create a file called `Dockerfile` in the `application` directory. The content of this file will be:

```bash
FROM node
RUN mkdir -p /usr/src/app
COPY index.js /usr/src/app
EXPOSE 8080
CMD [ "node", "/usr/src/app/index" ]
```

> **Note:** If you don't understand how a Dockerfile works, check out [this reference](https://docs.docker.com/engine/reference/builder/).

After that we need to create an image, from this `Dockerfile`, which can be done through the following command:

```bash
docker build -t load-balanced-app .
```

And then we can run both instances of our application with the following commands:

```bash
docker run -e "MESSAGE=First instance" -p 8081:8080 -d load-balanced-app
docker run -e "MESSAGE=Second instance" -p 8082:8080 -d load-balanced-app
```

After running both commands, we will be able to open both instances on a web browser by going to `http://localhost:8081` and `http://localhost:8082`. The first URL will show a message saying "First instance", the second URL will show a message saying "Second instance".

## Load Balancing with a Dockerized NGINX Instance

Now that we have both instances of our application running on different Docker containers and responding on different ports on our host machine, let's configure an instance of NGINX to load balance requests between them. First we will start by creating a new directory.

```bash
mkdir nginx-docker
```

In this directory, we will create a file called `nginx.conf` with the following code:

```bash
upstream my-app {
    server 172.17.0.1:8081 weight=1;
    server 172.17.0.1:8082 weight=1;
}

server {
    location / {
        proxy_pass http://my-app;
    }
}
```

This file will be used to configure NGINX. On it we define an [`upstream`](http://nginx.org/en/docs/http/ngx_http_upstream_module.html) group of servers containing both URLs that respond for the instances of our application. By not defining any particular algorithm to load balance requests, we are using round-robin, which is the default on NGINX. There are several other options to load balance requests with NGINX, for example [the least number of active connections](http://nginx.org/en/docs/http/ngx_http_upstream_module.html#least_conn), or [the least average response time](http://nginx.org/en/docs/http/ngx_http_upstream_module.html#least_time).

After that, we define a `server` property that configures NGINX to pass HTTP requests to `http://my-app`, which is handled by the `upstream` defined before. Also, note that we hardcoded `172.17.0.1` as the gateway IP, this is the default gateway when using Docker. If needed, you can change it to meet your local configuration.

Now we will create the `Dockerfile` that will be used to *dockerize* NGINX with this configuration. This file will contain the following code:

```bash
FROM nginx
RUN rm /etc/nginx/conf.d/default.conf
COPY nginx.conf /etc/nginx/conf.d/default.conf
```

Having created both files, we can now build and run NGINX containerized on Docker. We achieve that by running the following commands:

```bash
docker build -t load-balance-nginx .
docker run -p 8080:80 -d load-balance-nginx
```

After issuing these commands, let's open a web browser and access `http://localhost:8080`. If everything went well, we will see a web page with one of the two messages: `First instance` or `Second instance`. If we hit reload on our web browser a few times, we will realized that from time to time the message displayed switches between `First instance` and `Second instance`. This is the round-robin load balancing algorithm in action.

<include src="TweetQuote" quoteText="Learn how to load balancing Node.js apps with NGINX and Docker."/>

> **Note:** To use the other algorithms available on NGINX, [check their documentation for more information](https://www.nginx.com/resources/admin-guide/load-balancer/).

<include src="asides/Node" />

## Conclusion

Loading balancing applications with Docker and NGINX is an easy process. In this article we have managed to achieve this goal with a few simple steps. All we had to do was to install Docker on our development machine, run two instances of a *dockerized* applications and then configure a *dockerized* NGINX instance to round-robin requests to the application instances.

To learn more about **load balancing, NGINX and Docker**, check out the following resources:

- [Using nginx as HTTP load balancer](http://nginx.org/en/docs/http/load_balancing.html)
- [NGINX Load Balancing - HTTP and TCP Load Balancer](https://www.nginx.com/resources/admin-guide/load-balancer/)
- [How to Set Up NGINX Load Balancing](https://www.digitalocean.com/community/tutorials/how-to-set-up-nginx-load-balancing)
- [Docker Swarm Load Balancing with NGINX and NGINX Plus](https://www.nginx.com/blog/docker-swarm-load-balancing-nginx-plus/)
- [How to run a load-balanced service in Docker containers](http://superuser.openstack.org/articles/run-load-balanced-service-docker-containers-openstack/)


"docker"