If you are coming here from part 2 of the series you will recognize the setup here.
In this blog we are going to go step by step through the process of building a Docker Swarm in Azure running on CentOS.The audience for this blog post is anyone who has an interest in Docker and or Azure. There is very little assumed knowledge other than a power user's level of knowledge and how to use ssh or Putty. This post is written in a simple way to guide the uninitiated thru the process. The take away from this blog post will be an enhanced knowledge of both Docker and Azure.You will also have a functioning non-prod, Docker Swarm, running Nginx web servers horizontally scaled in the Azure cloud!
RexRay is a plugin module available for use with Docker which provides the ability to use shared storage as a Docker volume. It is quick to setup and provides near seamless data sharing between containers. We review it's basic design and detail tips for it's use in the AWS environment. The plugin design supports many different environments.
Most systems are composed of multiple applications. An orchestration mechanism is needed to start the applications when needed and in the correct order. A typical modern application may consist of a database such as MongoDB and a web service implemented using NodeJS. The web application may provide a number of API services accessible via a http ReST interface. Testing those services will require test tools that can send requests to the http interface and evaluate the results returned such as http status codes and response content.
In our example today we are going to discuss how to create a simple web server (IIS) and run it in a container . We will also inject some of our custom HTML for the example. The prerequisite for this lab would be to have a Windows 2016 server running Docker.
This is the first of a few related posts on the subject of the importance of controlling and constraining your AWS account resource creation abilities particularly in terms of IAM accounts.
A recent lesson learned caused us to research the area of unexpected resource usage in an AWS account. Trying out the AWS Batch service inadvertently resulted in the launch of an EC2 c4.large instance which ran for a day before we noticed that it was running. This was a surprise because the launch was not explicit, nor was the instance tagged with a descriptive name. After terminating the instance we realized that with this particular account only a limited set of instance types should ever be run and the AWS Config service can be used to detect things outside of normal operational expectations.
AWS Config can be set up using rules that are evaluated and a report generated for anything that fails the rule checks. In this case a rule was created listing the 3 instance types that would be expected to be found for this account. When the Config rules are checked any instance not falling in that list will be reported as non compliant. Note that this service does not prevent the launch of out of norm types but only reports on them so you have to take the action to correct the issue. A subsequent post will cover how IAM policies can be used to prevent a launch in the first place.
At this year’s Red Hat Summit, Vizuri had a blast presenting on how to quickly create and publish native, secure mobile applications that integrate with various middleware components deployed as micro-services. We took the architecture we discussed in our teaser blog post and added in 3Scale to add consistent management and security to the backend micro-services.
Subscribing to our blog is a great way to stay up to date with the latest information from Vizuri, as well as our strategic partners. We focus on providing a range of content that is practically useful and relevant from both a technical and business perspective.