Deploying a SSL Protected Containerized App: Part 1


One of the greatest motivations for me is seeing the current open-source projects. It is amazing to be apart of a community that truly transcends race, age, gender, education that culminates in the development of society changing technologies, it is not difficult to be optimistic about the future.

With that, lets deploy a containerized application behind a Nginx Reverse Proxy with a free SSL encrypted. This entire deployment will only cost you a domain.

Technologies Used

The technologies used in this series are:


Figure 1: Application Architecture

Getting Started

To start, I would advise signing up to a Azure trial . This will help you get started without any hassle.

If you have your own hosted VM or are doing a locally hosted docker stack please feel free to skip this part and move onto part 2.

Deploying the Virtual Machine

Select the image

Figure 2: Selecting a VM
  1. In the side menu press Virtual Machines
  2. Press “Add”
  3. Select the “CentOS-based 7.4” image
  4. Press “Ok”

Note: Technically you can use any image that can run docker. 

Configure the machine

Figure 3: Configuring basic settings
  1.  Name the VM – ie. DockerHost
  2. Change disk type to HDD (To save credit)
  3. Set the username
  4. Change authentication type to password for simplicity
  5. Set the password
  6. Confirm the password
  7. Create a new Resource Group (Such as SSLTest)

Select Machine Size

Figure 4: Selecting a VM Size
  1. Select a machine size, I chose the D4S_V3 (4 vCPUs, 16GB) however any image with 2 or more vCPUs and more than 8GB of RAM is sufficient.

Virtual Machine Settings

Figure 5: Configuring VM settings

You can leave default settings for the settings. (I switched off auto-shutdown).

Note: Make sure public IP address has been enabled

Wait for the Virtual Machine to finishing deploying…

Configuring DNS

Find the public IP address

After the machine has been successfully configured, browse to the virtual machine in Azure and get the public IP.

Figure 6: Identifying the public IP

Create the TXT file

Log onto your domain provide (i.e. and create a TXT file to point your domain address to the newly created VM.

Figure 7: Creating a TXT record

Do a simple “nslookup ​​<domain>” till you can confirm that the domain has been updated.

Opening up ports 443, 80, 22

Figure 8: Editing network interfaces


Browse to the virtual machine and browse to “Networking” in Azure. The following ports need to be allowed for inbound traffic

443 – This will be used to receive the SSL protected HTTPS requests

80 – This will be used temporarily to recieve your SSL certificate

22 – This should be open already however if it isn’t, allow 22 traffic for SSH connections.

SSH into the VM and allow root access (Dev only)

Using putty if you are on windows or just terminal on a Mac or Linux workstation, attempt to SSH into the machine.

After successfully logging in (Using the specified credentials when creating the VM), enable the root user for ease of use for the purpose of this tutorial (Do not do this for production environments).

This can be done by running

sudo passwd root

Specify the new root password

Confirm the root password

Congratulations you have completed part 1 of this tutorial, now that you have a virtual machine ready, let move on to part 2.


Hook-line and sinker…

Now that I have your attention, let’s have a rational conversation about buying cryptocurrencies. Quick test to see whether this article will be a waste of your time.

  1. Do you understand the relationship between time and risk?
  2. Do you own ETF’s, Index Funds or have money in a Robo-advisor?
  3. Do you understand compound interest?
  4. If I give you 101% return on a flip of a coin, should you take it?
  5. Do you have more than 4 months of expenses in a spending account or bank savings account?

If your answer to the first 4 was “Yes” than go ahead and skip this article. If your answer to 5 was yes…personally message me immediately so we can discuss the list of things you need to do before you invest in crypto…

It goes without saying that I am not a professional financial adviser and do not take any responsibility for any decisions you as a rational adult make.

(P.s. Calculations could be wrong.)

Lets start.

Risk vs. Return

It is important to understand the relationship between risk and return not only in finance but also life. Go snowboarding potentially break a leg. Ask a girl out, she says yes…than dumps you 5 days later, that’s life (That one still hurts).

The relationship between risk and return in gambling is very easy to understand.


If for every $1 you gambled, I gave you $3 if its heads and you lose the $1 if its tails would you take the gamble?

The university answer is yes, you should always take the bet because you have a positive Return / Risk (3/2 = (1.5/1 – 1) or 50%). This means that over the long run, you should theoretically get ROI of 50% on investment ie. take this bet as often as possible.

Over the long run

Something key was just mentioned, “over the long run“. Why does the time matter in this gambling example? Very simply, because the odds are in your favor, the more often you take the gamble, the higher the probability you will gain 50% overall which will approach 100% certainty.

To demonstrate this concept, lets take our game of heads and tails where you bet $1, get back $3 if you win and play it twice, reinvesting the winnings (Heads = Win):

On the left is the probability, on the right are the outcomes.




The simple formula for calculating return vs risk:

Estimated ROI =(probability * outcome)/originalInvestment – 1

In round 1 the return is calculated as 50% ($3 * 0.5 – $1). Nice job on taking the bet!

Now lets do the second round.

There are four outcomes so it is .25 chance that you will get $9 return.

Calculating that in we get 125% (($9*.25)/$1 – $1). Wait a minute?!!! How did the Estimated return gets bigger, we took the same odds…

This is the intimate unappreciated relationship between time and money, when odds are good, the more “times” you make that investment the better off you are.

Catch 22

Here is the thing, if you have played the flipping game enough and accrued enough to retire, would you still risk it all to 3x? The short answer is no. Money has a depreciating return on individuals (Unless you are insatiable) and as people gain more money, they tend to rightly choose more risk adverse options (This does not necessarily hold true for the extremely wealthy). In the coin game, you could lose everything on a 50% coin flip… That’s very scary. If you make the choice not to make that flip, not only should you not be judged, I applaud you for exercising financial restraint…Flip ya anyway…Huon, Saxon?!

What you were waiting for…

The ideas expressed in this article are relatively simple concepts and for some reason when dealing with cryptocurrencies, people tend to throw away reason.


In conventional investments, due to regulation and financial market practices there is a fair amount of transparency in the associated risks. Things like liquidity risk is clearly disclosed in things such as Stocks.

In fact, more reason and care should be taken as even conventional risks have a fairly big cryptocurrency twist e.g.


Conventional Meaning Cryptocurrency Risk
Equity Risk The value of the equity is affected by the supply and demand of investors. Volatility is limited and large investors usually need to disclose large sale orders. Large whales own large amounts of certain cryptocurrencies. Any large sell off by a single investor could cause a fall-on effect due to the market uncertainty (ie. Imagine if Satoshi started selling his BTC).
Concentration Risk Lack of diversification in your portfolio means that specific changes in the underlying factors related to your investment (Industry, geography etc.) which may greatly increase your risk. Most cryptocurrencies are tied to a very specific idea or potentially only on currency utility. As such investing in a coin greatly increases your concentration in that one underlying factor. This is different from lets say investing in a more complex investment such as Apple stocks (Even if their iPhones fail, their MacBooks could be killing it)
Liquidity Risk The risk of not being able to get a good market value for your investment. This is most present in illiquid assets as transparency is very low in regards to market price.

There is a lot of associated uncertainty with selling off your cryptocurrency. If it is in a private wallet you need to move it, than onto an exchange. Due to the volatility, the moment you hit sell, the price of the asset may have dropped 5% no joke. There could even be a 5% difference in prices between exchanges.

WARNING! Technical Risks.

The arguably largest and most ignored risk for cryptocurrencies is something I call “Technical Risk”. The risk that a technical detail beyond the understanding of the investor may affect the investment.

Case and point Parity.

What is the required return to make up for the technical risk for cryptocurrencies? That is for you the investor to decide however some great every-man alternatives are

Robo-advisors such as Stockspot.

ETFs or Index funds are also a very effective investment vehicle.

If you continue to insist on Crypto than a diversified approach such as C20 are a much safer approach.

Please at least read the White Papers of any ICO you participate in…

The real secret is cryptocurrency is not for the lazy. Do not HODL especially if you have met your investment horizon or goal (Look up BCC). Technical Risk may increase (i.e. developer teams leaving the project). Pay attention and try to understand the risks. Do not get emotionally attached! You are not some savant of finance for choosing ETH@$30.

Me? I am going to keep investing into crypto because Yolo, but definitely don’t copy me.

N-tier Identity Provider – Why?

Cheat Sheet (For the university kids)

  • Distributed Architecture is the “bees knees” in web technology (scalability, dependency management & service management)
  • Stateless communication is ideal for single page applications as view generation logic is completely separate from application data logic.
  • Authentication is required on every request in stateless communication
  • Identity can be shared between applications
  • Users want to experience Single-Sign-On especially in enterprise

Why the why?!

This post will be exploring the required understanding to derive the why of what we will be building in the next few weeks. Without a “WHY”, even with a “WHAT” and “HOW” the learning becomes meaningless. Armed with a “WHY” I genuinely believe even without touching a piece of code, project managers, technical operations and even the everyday user can benefit from understanding the goal of this series.

Modern Software Architecture

In modern web-based technology, distributed architecture is key.

Distributed architecture has 3 key functions:

  1. Clearly defined dependencies
  2. Efficient scaling
  3. Re-usable components

No area does this hold more true for than in “Identity”. A user can be thought of as a persistent record (Or partial record) not only within a entire app but also across different apps. The question “Identity” aims to answer (to your app) is the same question your pubescent self once tried to answer:


To explore how this can be answered we first need to understand the two basic forms of communication between server-client communication.

  1. Stateful
  2. Stateless

1. Stateful Communication

Stateful: The state of interaction is recorded therefore the context of communication can be derived not only from the information sent from client to server but also from previously established state.

Stateful Communication
Figure 1: High level stateful client-server communication
Why use stateful communication?

In some web-frameworks (Such as .NET MVC) UI rendering is done statically via generation of the source code (HTML, CSS & JavaScript) on server-side which is than sent to client-side. In the event of a partial re-render (Good example being filtering on a table) the server would require a understanding of what has previously been rendered to prevent unnecessary communication (Only sending to the client the new section not the entire page). This understanding or “State” is therefore stored on server and after establishment, all the client would need to do use this established state is send a reference.

As apart of this state-management you can also store the identity of the user and therefore handle security based on this state.

Why this is not my recommended approach.
  • Stateful communication is managed differently in different technologies, therefore it makes multi-technology environments difficult to develop and maintain (I.e. web-app + iOS app)
  • If identity is only maintained by client-server state, it makes it much more difficult (close to impossible) to create a smooth SSO experience
  • Communication is much more complicated as to understand the communication you also need to understand the state stored on server (Complicating debugging and unit testing).
Time and place

At university most my courses was learning stateful communication based technology (.NET 4.5, JSP, JSF etc…) but upon learning about single page applications I could immediately understand the weaknesses of stateful communication. Without the requirement of server-side view generation, the benefits of stateful communication (admittedly there are some) do not outweigh the negatives. If you have a scenario where stateful communication is preferable (maybe a high-frequency polling web-application where the security verification overhead of communication would be too high in stateless communication) I am keen to discuss and please comment below.

2. Stateless Communication

Stateless: The state of interaction is not-recorded beyond the request. All required context must be derived from the request sent.

Stateless Communication
Figure 2: High level stateless client-server communication
Why this is my recommended approach.

By never assuming state

  • request management is clear and very well scoped
  • following a request is as simply as sending the same request a second time
  • communication can be framed in a well-known multi-technology format (Such as the RESTFul architecture)
Terms and conditions apply.

Just with almost everything in life there is a compromise in stateless communication. As there is no state, every request needs to be separately authorized and validated. This would not be ideal if we were doing server-side rendering (Imagine having to re-authorize every resorting of a table! The horror!). Thankfully this has been largely solved through modern UI SPA (Single page application such as Angular or React (To be continued in another post)) frameworks where client-server communication is separated between UI Logic and Application-data Logic, therefore only application-data requests would need to be authenticated (Much more tolerable).


Hopefully by now you agree (Or disagree but commented) as to why we will be using stateless communication. Without a state however how will you be able to identify yourself to the application? Very simply, we need to send with our request a identification token (Or cookie) to ensure that the application server will take our request appropriately.

Simple enough? Now ask yourself… Why can’t we use that identification token between applications?! If my name is Tony on Facebook, why wouldn’t it be Tony on LinkedIn? The answer to this question is ABSOLUTELY we can use the same identification token, this rings true especially in Enterprise environments where your real identity matches your application identities.

Figure 3: High level Identity resolution

As depicted above, the “UserX” component of the application’s user identity is the same in every system therefore the UserX should be able to log into all 3 systems with the same identity. Each application than should be able to resolve the user independently and add on its own application specific Identity information (ie. Sales Manager, Employee Entitlement Id etc.).

Case and Point

This is the holy grail of UX. Ever use your google account to log into Dropbox? Or use Facebook to log into Instagram?! This is the “WHY” of this series. After this series, not only should you know how to authenticate your own Web-API with a existing identity provider (In this series we will explore OpenID Connect) but to build your own scalable “Identity Provider” ready to be used by ALL the applications you wish to share a Identity across.

Why we externalize the identity provider from our application is quite simple when looking at the diagram above. If we created a centralized identity based on another applications identity such as O365’s user identity (Which is possible), anytime O365 is taken offline, all your other applications would cease to be able to authenticate users (causing 100 help desks tickets and many upset users.) As such we separate the identity providing service as it is a super-dependency (Highest level dependency). There are product suites that do this separation for you.

The two I would recommend are AzureAD or Okta



In this series though we will be building this ourselves using Identity Server 4, Docker, Reddis, PostGRE and more because even if in production you want to “pay to make it go away” I believe there is still a educational experience to be had and all technology I will be using is either free or has a free community version.

Bonus for getting to the end (Starting architecture we will be building ;)).

Architecture V1