Did you know that with IBM UrbanCode Deploy, you can use a full-stack approach to simultaneously model both the application and infrastructure layers of your deployment? In this one-day, instructor-led course, you learn how the blueprint designer capabilities can make your cloud deployments easier.
Through hands-on labs, you use IBM UrbanCode Deploy in a cloud environment that integrates with an OpenStack back-end. You’ll get experience in these critical areas:
Modeling the cloud infrastructure and application layers
Provisioning environments and deploying software from blueprints
Creating and using configuration files
Updating a running environment
Using Git repositories to store and manage blueprints
To enroll in an instructor-led class with an IBM Global Training Partner, see the course information on the IBM Training and Skills web page.
Deploying applications in hybrid cloud environments is hard work. Your team spends most of the time maintaining your infrastructure, configuring dev/test and production environments, and deploying applications across environments – which can be both time consuming and error prone. But what if you could automate provisioning and deployment to deliver error free environments faster? What could you do with your free time?
Join our experts to learn about how IBM UrbanCode Deploy and IBM PureApplication provide a powerful combination of technologies that accelerate application deployment from days or weeks to just minutes – enabling your team to be the hero, not the bottleneck.
Attend this webcast to:
Learn about DevOps automation key concepts and best practices
See how a large financial services client reduced app deployment time by 90%
Hear how PureApplication and UrbanCode Deploy accelerate app delivery
Watch a brief demo that puts automation into practice
One of the riskiest and most manual parts of a deployment is updating the database schema. We’ve argued for years that you should automate these processes. The most common first step in that direction is to take the SQL scripts you’ve been using and treat them as incremental versions in IBM UrbanCode Deploy. That works, and the plugins for common databases like Oracle and Microsoft SQL Server make it easier.
We are big believers in capturing a “version” of the database as a whole that you can point at your prior database and it will figure out what changes are missing and make them in the correct order. Long time users of UrbanCode products will know that upgrades don’t come with instructions for the DBA. The installer just figures it out. Some of our customers are using the same utility and so there’s a plugin available for that.
Today, the database deployment problem is becoming increasingly common as organizations are getting the rest of their stack automated. The DBA’s are becoming a big bottleneck. Not surprisingly, there are some new solutions in this space. One that builds on the popular open-source LiquidBase is provided by Datical with a focus on enterprise capabilities and ease of use. There’s some pretty cool stuff in there, and now they’ve introduced a plugin for UrbanCode Deploy.
You should check out their demo of the integration:
Appurify provides an API accessible Cloud™ of real mobile devices with run-time debugging, optimization, and testing tools. Companies can automate testing of their apps on real devices directly from IBM® UrbanCode Deploy. The plugin allows you to provide an application, a testing script, and define the device type and environment characteristics and invoke your tests. Pretty nifty.
Details are on IBM PartnerWorld.
The Appurify team has also posted their source code.
Shunra Network Virtualization
Shunra NV integration for UrbanCode Deploy enables developers, testers and integrators to include network conditions into their testing, so communications between the tested application, virtualized users and virtualized services reflect the characteristics that will be experienced in production. Basically, if you need to see how your application will behave with extra latency between the front and back ends, or how your mobile app will work on one bar of connectivity, Shunra NV helps you test those scenarios.
Details of the integration are on IBM Partnerworld.
Reminder: Continuous Delivery is about Testing
Seeing these integrations helps remind me that DevOps is addicted to feedback, and a continuous deployment pipeline enables rapid testing as much as anything. Testing our complex applications means quickly getting changes into test environments and validating those changes as quickly as possible with as real-world a scenario as possible. With these two integrations, we see hooks into some clever technologies for getting to “real world”. Appurify streamlines testing on a real devices, while Shunra helps us test network conditions that are considerably worse than what we’d find in the test lab.
Building feedback loops by automatically kicking off testing after a deployment is something discussed in our white-paper: Deployment Automation Basics.
Deploying software requires getting the software from where it is (an artifact repository) to where it will run in the target environment. Beyond file transfer, there may be additional installation and configuration steps. There are two basic strategies for executing the deployment. You can either have a worker on the deployment target (an agent) or not. Both strategies have the concept of a central deployment server that acts as a controller determining when and how deployments occur.
In an agentless deployment (see Figure 1), the central deployment server is responsible for connecting to the deployment targets and executing the deployment steps, or actions.
The deployment server must log into the target machined when the deployment actions are “on the box.”. On UNIX style-operating systems, SSH is typically used while tools like PSExec and WinRM are may be used on Windows. Once logged in, the deployment server passes commands to the target machine for execution, may retrieve logs, and takes further action based on the responses.
Other deployments may not require a presence on the box. The middleware being deployed to may supply a remote deployment API, often a web service, to enable remote deployments. In the case of databases, a special URL is required.
Deployments with Agents
The second approach to deployment automation requires the installation of a worker process, an agent, to perform deployments. When the agent is installed on the deployment target (see Figure 2), it provides access to transfer files to, modify files on, and execute commands on the server being deployed to. Agents may also be used to connect to other targets that expose listeners.
Figure 2: Deployments with agents
Deployments that benefit from having direct access to the deployment target simply use an agent on that target. Access through systems like SSH and PSExec are not required.
Deployments to systems like databases and some application servers may not benefit from having a presence on the server may use an agent on the target anyway. Alternatively, a group of utility or “worker” agents may be used to interact with target systems using the same approaches an agentless approach would use.
Advantages of using agents
Simplicity and Ease of Use
An agent is a process that is running on a target server as some user. There is no need to maintain credentials to that machine for connectivity or script connections. Deployment actions are executed as though you are on the machine because your agent is.
Deployment scripts, in the form of plug-ins, are automatically cached on the target server and have their versions managed without any user effort.
Deployments through agents are as secure as, if not more secure than, deployments through other means. Any deployment requires a facility to install or upgrade software on a target. When comparing deployments through listeners such as web services, the usage profile of agented and agentless deployments is similar enough to be wash.
The security issues surrounding SSH and related tools are pretty clear. These facilities are listening for connections, most likely on standard ports. An attacker would expect this tool to be present, and could use off the shelf strategies to attack it.
With an agent that reaches out to its master server for instructions, there are no ports opened on the deployment target to attack the agent. A man in the middle attack (trying to get the agent to connect to a rogue master) is the most likely threat. With IBM UrbanCode Deploy this can be mitigated through a simple exchange of SSL certificates between agent and master. Further, the agent should be installed as a non-root service account so that it is limited to only touching the applications it manages in case the master server is compromised. This is also a best practice to help avoid accidents.
Offloading the work of performing a deployment from the Deploy Server to agents reduces the load on that master server allowing a single master to execute deployments that are more concurrent.
Further, in environments with particularly heavy usage, tools that establish a new connection for each deployment can run out of ports if the operating system is too slow to return ports used by terminated connections to the available pool.
Another issue arises when multiple network segments are in use, with firewalls between them. This is very normal when deploying to multiple data centers. In an agentless approach, a firewall exception allowing the master server to connect to each target would need to be requested, approved and configured. In IBM UrbanCode Deploy’s approach with agents, an Agent Relay pair is configured for each network segment. With a couple fast and limited firewall exceptions, networking issues are resolved for the entire network segment in a secure way.
If the central deployment server suffers an outage during a deployment, an agentless system will know a command started, but will not know the status. Generally, all deployments that were running at the start of the outage will be considered to have failed with the results of the most recent commands unknown. This is not a good situation to be in.
With agents, each step is ordered as a unit. With the work done by the agent, an outage of the central deployment server has no impact until the step is complete. If the server is down, the agent waits for it to come back, reports the results, passes back the logs, and accepts the next command. If the central servers are configured in a multi-master high availability configuration, the agent is directed to a different master and reports the results without skipping a beat.
Concerns with agents
There are some legitimate concerns around the use of agents. In IBM UrbanCode Deploy we have taken steps to address them.
Installing something on dozens, hundreds, or thousands of targets is a concern. Even if the installation is easy—and it is—any task multiplied by thousands could be painful. With UrbanCode Deploy, we have made sure that the agent’s installation can be automated.
If SSH is still active on the target host, you can list targets to push the agent to, through the UI, and it will install itself. Alternately, if you have a different automation agent already installed to manage the server infrastructure, the installer is designed to be run headless through automation. We even have a Puppet module and a Script Package for Pure Systems and SmartCloud Orchestrator.
Other customers have used built the built in agent installer steps to expose installing new agents as an UrbanCode Deploy process that can be invoked from within the tool or command line client.
Any additional process should be inspected for performance impacts. We have worked hard to keep the agents minimally invasive. They consume a small amount of memory, and nearly no processor power when active. Customers have installed our agents on trading systems where a performance impact of a millisecond could be extremely expensive only after carefully monitoring the agents. The impact of an idle agent is close to zero. A working agent will consume resources as it performs the deployment.
Deployments require some means of acting on a target server, either through listening execution services such as SSH, or an agent.
Using agents for deployments is generally preferable to the agentless model because it delivers more flexibility, ease of use, and power.
A system with agents can behave similarly to an agentless tool by using “worker agents”. However, by using several agents, deployment load can be spread out to boost capacity.
An agent based deployment tool like IBM UrbanCode Deploy can act like an agentless system while an agentless system cannot act like an agent-based tool. UrbanCode Deploy does an especially nice job in this respect by modeling deployment targets (resources) independently of agents.
With an agent-based system, you can take advantage of agents where the benefits outweigh the costs and perform remote deployments the rest of the time. Because modern agent management is very low cost due to automatic install and upgrade facilities, low performance impact, and tight security, agents will be the right choice the vast majority of the time.
Coming off the successful introduction of IBM UrbanCode Deploy 6.0 and IBM UrbanCode Release 6.0 in September, we are pleased to announce a set of new features and functionality for both solutions in their 6.0.1 releases.
Some of the new capabilities in UrbanCode Deploy are:
Tagging applications, components, agents, and resources to ease in grouping, navigating, and organizing complex applications and environments
Expanded z/OS support using Rexx scripts to extend deployable target environments of your multi-tier applications
WebSphere Portal as a target deployment platform
Enhanced WebSphere Application Server support
In UrbanCode Release you can now:
See precisely what is deployed across every environment and application in a release, compare environment content, and promote changes from one environment to another in a single view
View real-time progress of a major software release event, when multiple business units are contributing to a single, enterprise release spanning hundreds of applications
More detail on a few of these features will be available in later posts. In the meantime, you can read more about the release here.
Lara Ziosi has started a great series on extending IBM UrbanCode Deploy with two articles. One providing an introduction to using the command line interface (CLI) from within Groovy. The other shows how to use the REST interface using Apache Wink.
I have to say that the outpouring of great material like this from our new colleagues is one of the many pleasant surprises that has made joining the IBM family a whole lot of fun for the UrbanCode crew.
Lara’s blog is here: http://devblog.laraziosi.org/extensibility/