198 Lotus blogs updated hourly. Who will post next? Home | Blogs | Search | About 
Latest 7 Posts
Building the Release Definition
Wed, Apr 5th 2017 1
Creating A Dummy Service In Rancher
Tue, Apr 4th 2017 4
Adding A Dockerfile to the project
Mon, Apr 3rd 2017 6
Getting Your Rancher API Keys
Fri, Mar 31st 2017 3
Defining Your VSTS Build
Thu, Mar 30th 2017 3
A VSTS Build Agent For Rancher
Wed, Mar 29th 2017 3
Extending Your Rancher Environments
Tue, Mar 28th 2017 3
Top 10
Deciding on a frontend
Fri, Feb 3rd 2017 10
Managing your source code and issue tracking
Fri, Feb 10th 2017 9
But what about the data?
Mon, Feb 6th 2017 7
Who Are You?
Wed, Feb 8th 2017 7
Deploying Your Applications
Mon, Feb 13th 2017 7
Adding A Dockerfile to the project
Mon, Apr 3rd 2017 6
Getting To The Java Roots of XPages – Part 12
Thu, Mar 14th 2013 5
Reuse More Code With ThymeLeaf Layouts
Wed, Mar 22nd 2017 5
Hello… Hello… Is this thing still on?
Fri, Jan 27th 2017 4
Introducing ThymeLeaf Fragments
Tue, Mar 21st 2017 4

Deploying Your Applications
Twitter Google+ Facebook LinkedIn Addthis Email Gmail Flipboard Reddit Tumblr WhatsApp StumbleUpon Yammer Evernote Delicious
Declan Lynch    

So you have decided what you will write your application in, both backend and frontend, you have decided where you will store the source code and how you will track issues, you have figured out your authentication and authorization solution, all that is missing now is somewhere to actually run the application so people can use it. In the Domino world this was a simple solution, just put the NSF on the server, but when you leave the Domino world it because probably one of the hardest decisions.

First you need to know ‘HOW’ the application runs. If you have decided on Java for the backend then how does that run, do you deploy fat jar files that contain Tomcat web servers? Do you use skinny jar files that need to be deployed to an application server like WildFly or IBM Websphere Liberty. Using .NET then maybe you need to look at an IIS Server. What about the frontend? Where does that run do you need a server just for that or will it run on the servers the backend code is running on?

Then you need to ask if you will be running this all in-house or using a cloud provider like Azure, or Amazon Web Services. Do you use a container system like Docker or CloudFoundry?

At this stage you probably wish you could keep Domino around….

Because we decided to use Spring Boot we started looking at Pivotal CloudFoundry as our deployment solution but ultimately found that to deploy a Cloud Foundry solution on our Azure infrastructure might be very costly, it involved about 50+ VMs, additional cores and the Pivotal consultants we contacted really didn’t seem too interested in our business unless we were going to spend upwards of quarter of a million…

Next we looked at Docker. The best way to ‘think’ about docker is that you have a server which is the Docker host and then on that you have Docker containers which could be described as mini virtual machines, technically they aren’t but it is easier to think of them that way starting out. Docker on it’s own is just a technology stack just like HTTP is just a web stack. To make it useful you also need to look at Container Orchestration. This is the layer that manages all your Docker hosts and Docker Containers.

Orchestration layers include Docker Swarm (built in to Docker), Kubernetes, Apache MESOS and Cattle to name just a few. Cattle is one you may not hear of by that name but you may hear of Rancher. Rancher is the UI to Cattle but Rancher can also manage Docker Swarm and Kubernetes and it was this capability that draw me to looking at it. Rancher can also manage multiple environments so if you have a set of Docker hosts dedicated to your QA environment and a set of Docker hosts for your production environment then Rancher can keep them all separate for you.

So as you probably guessed we decided to deploy our applications using Docker containers running on Docker hosts which are running in Azure VMs using Rancher/Cattle as the orchestration layer. This turned out to be a great choice as we could then tie it all back in to our Microsoft Visual Studio Team Services build and release system which I’ll discuss in later posts.

Feb 13, 2017
8 hits

Recent Blog Posts
Building the Release Definition
Wed, Apr 5th 2017 12:30p   Declan Lynch
The Release definition in VSTS allows you to define the steps needed to be taken to deploy a build of your application to your deployment environments. On the Releases tab of your project you click on the ‘New Definition’ button and then select the ‘Empty’ profile. On the next screen it will automatically fill in your current VSTS project and the VSTS build definition so you can just go ahead and click Create. First things first is rename the autogenerated definition nam
Creating A Dummy Service In Rancher
Tue, Apr 4th 2017 12:30p   Declan Lynch
The last thing that we need to do before we can create the deployment scripts is to create a dummy service in Rancher that we can then replace with our deployed application. We need to do this because our deployment scripts need to reference a service id and will fail if the id doesn’t exist yet. In the Rancher interface create a new ‘Stack’ for your applications. Stacks are a way to organize different applications together. Give your stack a name and click on the create butto
Adding A Dockerfile to the project
Mon, Apr 3rd 2017 12:30p   Declan Lynch
Before we can deploy anything to Rancher it needs to be in a docker image so I’ll be asking my VSTS scripts to build a docker image that can then be uploaded to a Docker container/image repository before being deployed to the Rancher server. To create the Docker image I need a Dockerfile added to the project and I need to also tell my build script to copy it to a location that the release script can access. First I will create a new folder in my project under src/main called ‘docker&
Getting Your Rancher API Keys
Fri, Mar 31st 2017 12:30p   Declan Lynch
Before we can start the process of automatically deploying our application to Rancher we need to setup the API access keys that will allow you to use the Rancher Command Line Interface and API. Load up Rancher and log in as your administrator account and make sure that you are in the correct environment ( you will need to do this process in each environment that you will be deploying to ) and then go to the API menu. There are two kinds of API keys in Rancher. There are Account Keys and Environm
Defining Your VSTS Build
Thu, Mar 30th 2017 12:30p   Declan Lynch
The build definition in VSTS is designed to build and compile your code and then take the resulting build and save them to an artifact store. You can create build definitions for Visual Studio applications, XCode applications, Android applications and, of course, Java applications. In VSTS go to the Build & Release section of your project and then make sure you are on the Builds tab. Click on the New Definition button to get started. You should see a list of predefined build templates, th
A VSTS Build Agent For Rancher
Wed, Mar 29th 2017 12:30p   Declan Lynch
By default Visual Studio Team Services provides you with one hosted pipeline and one private pipeline when you are using the free services. You can add additional pipelines at a cost of $15 a month if you need them however a single pipeline should work ok for a small team. The private pipeline is something that you run on your own infrastructure and Microsoft provides pipeline agents that will run on Windows, OS X and Linux machines. These agents will listen to your VSTS account and accept jobs
Extending Your Rancher Environments
Tue, Mar 28th 2017 4:30p   Declan Lynch
In the last post we setup the Rancher server and added our first Rancher Host. One of the nice features of Rancher is that you can setup multiple environments so that you can keep your Development testing system separate from your QA system and separate from the Production system yet keep a single Rancher server orchestrating it all. Click on the ‘Environment’ tab and select the option to ‘Manage Environments’ The first thing I’m going to do is rename the Default e
Setting Up Your Rancher Infrastructure
Mon, Mar 27th 2017 9:30p   Declan Lynch
Before we can build and deploy our application we will need to first setup the infrastructure. I’ve decided that I’m going to be using Docker as the container service and Rancher as the orchestration layer. This blog post is just a quick overview of how to create a basic demo Docker/Rancher infrastructure. If you are considering using Docker/Rancher for production that I would highly encourage you to do plenty of additional research beyond this posting before setting anything up. Fo
AJAX and ThymeLeaf For Modal Dialogs
Fri, Mar 24th 2017 8:30p   Declan Lynch
The final part of the basic phonebook application is being able to click on a person and see details about them. For this part I’ve decided for now not to open a new page but to open the persons details in a modal dialog box on the current screen just so I can demo how to do ajax calls using Spring and Thymeleaf. First of all I need a PersonController which will populate the modelmap with the selected persons attributes and then return a thymeleaf page. This controller is very simple an
Highlighting The Selected Area With Thymeleaf
Thu, Mar 23rd 2017 4:30p   Declan Lynch
Now that I have pulled the side navigation menu out in to its own reusable code fragment I can now make a small adjustment to it to highlight the currently selected option in the navigator. In the Domino/XPage world this would be the script that you write to add a css class to a menu item using the selected property. For the bootstrap based side navigator that I am using in this application you can add a background color to the side navigator by adding a css class of ‘active’ to the

Created and Maintained by Yancy Lent - About - Planet Lotus Blog - Advertising - Mobile Edition