A lot of organizations are using ServiceNow to manage requests for creating new compute resources in the could ( i.e servers, lambda functions, containers …)
Usually, CMP tools like Scalr, or even ServiceNow Cloud Management can ( to a certain degree ) automate this process, but there are two major issues with these approaches :
1 – For these tools to be used properly they need lengthy customization to fit the business architecture of the organization, mapping all the business units, integrating with existing tools …
2 – It can be expensive, the price per node model can add up quickly for companies with a large number of servers deployed.
This a way to automate server build by using ServerNow Orchestration Module, and Serverless to build the integration.
Creating ServiceNow Form
ServiceNow workflow
to simplify the process I’ve only used a simple RunScript Step, other activities can be added like CMDB integration, approvals, notifications, etc …
here is a look at what the script does :
Gets all the parameters from the form
make an API call to API Gateway and Lambda
Lambda will trigger
[code]
var os = current.variables.os;
var inst_size = current.variables.inst_size;
var request = new sn_ws.RESTMessageV2();
request.setEndpoint(‘https://9drnhpoorj.execute-api.us-east-1.amazonaws.com/dev/instance’);
request.setBasicAuth(“apikey1″,”mutKJWAolpsdfsdflksd8ndew02234LNFQQvq”);
request.setHttpMethod(‘POST’);
request.setRequestHeader(“Accept”, “application/json”);
request.setRequestHeader(‘Content-Type’, ‘application/json’);
GuardDuty (announced in the 2017 edition of AWS Re:Invent) , is a managed threat detection service that continuously monitors for malicious or unauthorized behavior to help you protect your AWS accounts and workloads. It monitors for activity such as unusual API calls or potentially unauthorized deployments that indicate a possible account compromise. GuardDuty also detects potentially compromised instances or reconnaissance by attackers.
with a minimal amount of code, and few clicks in the AWS console we can set up guardduty to scan EC2 fleets for eventual threats, notify a lambda function to stop the compromised instances and send an SMS notification using AWS SNS service:
1- Testing few threats :
1-a – Bitcoin mining : one of the possible threats is using your EC2 instances for bitcoin mining , I started a bitcoind container on my EC2 instance to :
1-b SSH brute-force : I’m not using any username and passwords dictionaries
2- SNS topic : create an SNS topic called guardduty_alerts, with an SMS subscription
3- Lambda: for stopping instances and sending notifications
#
result = json.loads(event)# result is now a dict
instanceId = event[‘detail’][‘resource’][‘instanceDetails’][‘instanceId’]
type = event[‘detail’][‘description’]
message = “your EC2 instance ” + instanceId + “has been compromised by attack of ” + type + “, it will be stopped”
sns.publish(
TopicArn = topicArn,
Message = message
)
Minio is a local cloud object storage server, it’s open source, released under Apache License V2.0, allowing developers and devops to have a local and a public cloud storage to:
backup VMs
backup containers
store unstructured Data ( photos, files, …)
store objects in AWS S3
store objects using SDKs (GO, Javascripts, Java )
to start a server you can use the container image of MiniO available on Docker hub here :
I have been browsing the internet for blogs or articles to help Chef developers have a way of promoting the code of their cookbooks, a way of vetting code, and avoiding that code goes from Operations guys straight to production.
I have found a lot of theoretical articles on building a CI pipeline for chef cookbooks, but not a lot of practical ones, so I decided to make a proof of concept for the public and my team as well.
when it comes to integration tools, I like Jenkins, it’s open source and the community is very active in adding and updating plugins .
In this example I will use a Java cookbook as a code base, and I will be running 4 test :
Foodcritic : a helpful lint tool you can use to check your Chef cookbooks for common problems. It comes with 61 built-in rules that identify problems ranging from simple style inconsistencies to difficult to diagnose issues that will hurt in production.
ChefSpec : a unit testing framework for testing Chef cookbooks. ChefSpec makes it easy to write examples and get fast feedback on cookbook changes without the need for virtual machines or cloud servers.
Rubocop : a Ruby static code analyzer. Out of the box it will enforce many of the guidelines outlined in the community Ruby Style Guide.
Test Kitchen : a test harness tool to execute your configured code on one or more platforms in isolation. A driver plugin architecture is used which lets you run your code on various cloud providers and virtualization technologies such as Amazon EC2, Vagrant, Docker, LXC containers, and more. Many testing frameworks are already supported out of the box including Bats, shUnit2, RSpec, Serverspec, with others being created weekly.
of course you can have all these tools in one package…. the famous ChefDK
Code Promotion :
The concept of code promotion helps the CI process distinguish between good and bad builds, I like to define a good build as a build where ALL the tests are successful .
Jenkins helps you implement this concept with a community plugin : Promoted Build Plugin
based of the status of your build ( promoted of not) you can control the code that goes into your repository (github or gitlab), you can use set up hooks to deny merge requests from builds that are not promoted.
Jobs:
let’s setup our jobs, we will too categories of jobs :
Build Jobs
Test Jobs
whenever a build job is successful will trigger all the test jobs to start.
Build-java-cookbook : will clone the code repo and create a temporary artifact, this is the config section for this job
Rubocop Test : will copy the temporary artifact decompress it to have all code repo and run rubocop test on the code :
ChefSpec Test:
FoodCritic :
Test Kitchen :
Test Kitchen will spin a vagrant box (ubuntu-14.04) and run the cookbook on it and test the results.
First Run :
with the configurations above we run the build and test jobs :
Result :
Rubocop test failed, by looking at the execution log we can see why :
+ rubocop
Inspecting 44 files
.......CC...CC........C..C..................
Offenses:
providers/alternatives.rb:34:38: C: Use shell_out("#{alternatives_cmd} --display #{cmd} | grep #{alt_path} | grep 'priority #{priority}$'").exitstatus.zero? instead of shell_out("#{alternatives_cmd} --display #{cmd} | grep #{alt_path} | grep 'priority #{priority}$'").exitstatus == 0.
alternative_exists_same_prio = shell_out("#{alternatives_cmd} --display #{cmd} | grep #{alt_path} | grep 'priority #{priority}$'").exitstatus == 0
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
providers/alternatives.rb:35:28: C: Use shell_out("#{alternatives_cmd} --display #{cmd} | grep #{alt_path}").exitstatus.zero? instead of shell_out("#{alternatives_cmd} --display #{cmd} | grep #{alt_path}").exitstatus == 0.
alternative_exists = shell_out("#{alternatives_cmd} --display #{cmd} | grep #{alt_path}").exitstatus == 0
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
providers/alternatives.rb:43:18: C: Use remove_cmd.exitstatus.zero? instead of remove_cmd.exitstatus == 0.
unless remove_cmd.exitstatus == 0
^^^^^^^^^^^^^^^^^^^^^^^^^^
providers/alternatives.rb:57:18: C: Use install_cmd.exitstatus.zero? instead of install_cmd.exitstatus == 0.
unless install_cmd.exitstatus == 0
^^^^^^^^^^^^^^^^^^^^^^^^^^^
providers/alternatives.rb:66:28: C: Use shell_out("#{alternatives_cmd} --display #{cmd} | grep \"link currently points to #{alt_path}\"").exitstatus.zero? instead of shell_out("#{alternatives_cmd} --display #{cmd} | grep \"link currently points to #{alt_path}\"").exitstatus == 0.
alternative_is_set = shell_out("#{alternatives_cmd} --display #{cmd} | grep \"link currently points to #{alt_path}\"").exitstatus == 0
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
providers/alternatives.rb:72:16: C: Use set_cmd.exitstatus.zero? instead of set_cmd.exitstatus == 0.
unless set_cmd.exitstatus == 0
^^^^^^^^^^^^^^^^^^^^^^^
providers/alternatives.rb:87:50: C: Use cmd.exitstatus.zero? instead of cmd.exitstatus == 0.
new_resource.updated_by_last_action(true) if cmd.exitstatus == 0
^^^^^^^^^^^^^^^^^^^
providers/ark.rb:39:20: C: Omit parentheses for ternary conditions.
package_name = (file_name =~ /^server-jre.*$/) ? 'jdk' : file_name.scan(/[a-z]+/)[0]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
providers/ark.rb:134:14: C: Use 0o for octal literals.
mode 0755
^^^^
providers/ark.rb:149:14: C: Closing method call brace must be on the line after the last argument when opening brace is on a separate line from the first argument.
))
^
providers/ark.rb:150:16: C: Use cmd.exitstatus.zero? instead of cmd.exitstatus == 0.
unless cmd.exitstatus == 0
^^^^^^^^^^^^^^^^^^^
providers/ark.rb:157:16: C: Use cmd.exitstatus.zero? instead of cmd.exitstatus == 0.
unless cmd.exitstatus == 0
^^^^^^^^^^^^^^^^^^^
providers/ark.rb:164:16: C: Use cmd.exitstatus.zero? instead of cmd.exitstatus == 0.
unless cmd.exitstatus == 0
^^^^^^^^^^^^^^^^^^^
providers/ark.rb:172:14: C: Use cmd.exitstatus.zero? instead of cmd.exitstatus == 0.
unless cmd.exitstatus == 0
^^^^^^^^^^^^^^^^^^^
recipes/ibm.rb:44:8: C: Use 0o for octal literals.
mode 00755
^^^^^
recipes/ibm_tar.rb:36:8: C: Use 0o for octal literals.
mode 00755
^^^^^
recipes/ibm_tar.rb:49:8: C: Use 0o for octal literals.
mode 00755
^^^^^
recipes/set_java_home.rb:27:8: C: Use 0o for octal literals.
mode 00755
^^^^^
recipes/set_java_home.rb:32:8: C: Use 0o for octal literals.
mode 00755
^^^^^
resources/ark.rb:39:54: C: Use 0o for octal literals.
attribute :app_home_mode, kind_of: Integer, default: 0755
^^^^
44 files inspected, 20 offenses detected
Build step 'Execute shell' marked build as failure
Finished: FAILURE
let’s go ahead and fix these offenses and commit the code :
we restart the build :
and here everything is green this time :
from this point on you can create do two things :
save your cookbook in a private supermarket with a corresponding version number
upload this cookbook to chef server
Promotion status :
After the completion of all tests, this build can now be promoted.
until today I knew that running containers was always dependent on the existence of a host and an OS of some kind, but I came across this project : vSphere Integrated containers, it’s a runtime environment allowing developer to run containers as VMs, instead of running containers in VMs .
is CLI tool allowing for the creating of containerVMs in the following setups :
vCenter Server with a cluster
vCenter Server with one or more standalone ESXi hosts
A standalone ESXi host
this architectures relies on a Virtual Container Host, the VHC is an end point to start, stop, delete containers across the datacenter .
“The Virtual Container Host (VCH) is the means of controlling, as well as consuming, container services – a Docker API endpoint is exposed for developers to access, and desired ports for client connections are mapped to running containers as required. Each VCH is backed by a vSphere resource pool, delivering compute resources far beyond that of a single VM or even a dedicated physical host. Multiple VCHs can be deployed in an environment, depending on business requirements. For example, to separate resources for development, testing, and production.”
download the ISO file from vmware wbesite : https://my.vmware.com/en/web/vmware/evalcenter?p=free-esxi6
use virtualbox or vmware fusion to create a host using esxi host ( http://www.vmwareandme.com/2013/10/step-by-step-guide-how-to-install.html#.V6a8rZNViko)
Creating a Virtual Container Host :
$ vic-machine-darwin create –target 172.16.127.130 –user root –image-datastore datastore1
INFO[2016-08-06T14:05:48-05:00] Please enter ESX or vCenter password:
INFO[2016-08-06T14:05:50-05:00] ### Installing VCH ####
INFO[2016-08-06T14:05:50-05:00] Generating certificate/key pair – private key in ./virtual-container-host-key.pem
INFO[2016-08-06T14:05:50-05:00] Validating supplied configuration
INFO[2016-08-06T14:05:51-05:00] Firewall status: ENABLED on “/ha-datacenter/host/localhost.localdomain/localhost.localdomain”
INFO[2016-08-06T14:05:51-05:00] Firewall configuration OK on hosts:
INFO[2016-08-06T14:05:51-05:00] “/ha-datacenter/host/localhost.localdomain/localhost.localdomain”
WARN[2016-08-06T14:05:51-05:00] Evaluation license detected. VIC may not function if evaluation expires or insufficient license is later assigned.
INFO[2016-08-06T14:05:51-05:00] License check OK
INFO[2016-08-06T14:05:51-05:00] DRS check SKIPPED – target is standalone host
INFO[2016-08-06T14:05:51-05:00] Creating Resource Pool “virtual-container-host”
INFO[2016-08-06T14:05:51-05:00] Creating VirtualSwitch
INFO[2016-08-06T14:05:51-05:00] Creating Portgroup
INFO[2016-08-06T14:05:51-05:00] Creating appliance on target
INFO[2016-08-06T14:05:51-05:00] Network role “client” is sharing NIC with “external”
INFO[2016-08-06T14:05:51-05:00] Network role “management” is sharing NIC with “external”
INFO[2016-08-06T14:05:52-05:00] Uploading images for container
INFO[2016-08-06T14:05:52-05:00] “bootstrap.iso”
INFO[2016-08-06T14:05:52-05:00] “appliance.iso”
INFO[2016-08-06T14:06:00-05:00] Waiting for IP information
INFO[2016-08-06T14:06:18-05:00] Waiting for major appliance components to launch
INFO[2016-08-06T14:06:18-05:00] Initialization of appliance successful
INFO[2016-08-06T14:06:18-05:00]
INFO[2016-08-06T14:06:18-05:00] vic-admin portal:
INFO[2016-08-06T14:06:18-05:00] https://172.16.127.131:2378
INFO[2016-08-06T14:06:18-05:00]
INFO[2016-08-06T14:06:18-05:00] DOCKER_HOST=172.16.127.131:2376
INFO[2016-08-06T14:06:18-05:00]
INFO[2016-08-06T14:06:18-05:00] Connect to docker:
INFO[2016-08-06T14:06:18-05:00] docker -H 172.16.127.131:2376 –tls info
INFO[2016-08-06T14:06:18-05:00] Installer completed successfully
you can use vSphere or ESXI web client to take a look :
creating ContainerVM :
$ docker –tls run –name container1 ubuntu
the container has been created :
Conclusion :
ContainerVMs seem to have the following distinctive characteristics over the traditional containers :
There is no default shared filesystem between the container and its host
Volumes are attached to the container as disks and are completely isolated from each other
A shared filesystem could be provided by something like an NFS volume driver
The way that you do low-level management and monitoring of a container is different. There is no VCH shell.
Any API-level control plane query, such as docker ps, works as expected
Low-level management and monitoring uses exactly the same tools and processes as for a VM
The kernel running in the container is not shared with any other container
This means that there is no such thing as an optional privileged mode. Every container is privileged and fully isolated.
When a containerVM kernel is forked rather than booted, much of its immutable memory is shared with a parenttemplate
There is no such thing as unspecified memory or CPU limits
A Linux container will have access to all of the CPU and memory resource available in its host if not specified
A containerVM must have memory and CPU limits defined, either derived from a default or specified explicitly
but the traditional containers like Docker are definitely a more mature solution, offers more tools for orchestration and scaling.
Riak is some hot stuff lately with the increasing need for clusterzitation in the world of NoSQL data stores .
Riak is a solution to big data problem, it was based on Amazon Dynamo design, to respond to request at a very large scale,
Basho introduced Riak as fault tolerant, simple, scalable, high availability friendly .
it’s fairly easy to create/add nodes with riak-admin to a riak cluster, but if this is combined with docker-compose capabilities it will give you the possibility to have an easily deployable/scalable cluster of riak nodes.
I created a docker-compose yaml to specify all the components of the cluster, basically a seed and a set of nodes
I used Hectcastro Riak docker image, because : that’s the beauty of containers, they are reusable !