Tag: PaaS

  • Docker is red hot at Red Hat

    The news from the Red Hat Summit this weeks almost appears to be all Docker all the time.  A series of announcements has made Docker clearly the container of choice for Red Hat users. But don’t stop at just Red Hat. Docker has pretty much locked down all of the major Linux distros including Amazon’s AWS Linux version with more on the way. More on this on Network World here.

    Here is a recap of the news:

    http://blog.docker.io/2014/04/docker-red-hat-even-more-goodness/

    • Expansion of RHEL 7.0 Beta to include Docker container technologies.  Red Hat Enterprise Linux 7 is currently in beta and is targeted to be a Red Hat certified container host, with Docker as a primary supported container format;

    • Docker Integration with OpenShift PaaS.  Application containers in OpenShift will be integrated with Docker and support Red Hat certified ISV applications packaged in the Docker container format. These same containerized applications will also be supported on other Red Hat products;

    • Red Hat Certification.  As revealed last month, Red Hat is launching certification of applications delivered in the Docker container format – Dockerize All The Things!

    • One More Thing.  Finally, in addition to the above, for enterprise IT orgs conducting projects with Docker and Red Hat, Docker, Inc. has developed additional service offerings, including developer support and a JumpStart program.

  • Docker as a framework for your DevOps culture

    Docker as a framework for your DevOps culture

    If you’re like me and spend a lot of time evaluating new technologies with the goal of “doing more faster” with your engineering organization, then you’re certainly aware of the many choices of DevOps tools like Puppet, Chef, Ansible, Salt, etc. In my opinion each of these tools is amazing at one piece of the DevOps puzzle – configuration management, and some are OK at other DevOps tasks. Each of the tools has a slightly different approach to configuration management but after comparing them I find that you’re usually picking a tool based on stylistic reasons like the DSL, existing recipes/playbooks, or existing familiarity. While I have my opinion on which of the above tools is “the best”, each tool only solves the configuration management piece of the puzzle.

    If DevOps is truly a culture change and not just the codification of operational tasks then we need tools that help foster that culture and I think Docker goes a long way towards doing that.

    Coming from the perspective of a developer looking at development tools, I see the above tools as APIs for DevOps, where Docker is more of a framework for DevOps. This is because Docker is both a runtime environment and a configuration management tool in one. Best of all Docker eliminates many common tasks in your development cycle and creates a tighter feedback loop between your development and operational tasks. I believe creating fast effective feedback loops between development and operations is critical weather development and operations are entire departments or simply tasks in within your organization.

    In my experience developing software as a service platforms, one of the most problematic parts of the process is the management of the environments, how many times have you heard “works for me” or “works on our test servers”? Generally issues like this arise from subtle dependency changes between the environments introduced by both developers, QA and operations throughout the deployment lifecycle. To fix this problem I’ve seen, and attempted, several approaches. For example I’ve tried having a base VM and using Vagrant with Puppet or Chef to create local environments that were the same as test and production environments. This seems to work at first but it proved to be cumbersome to manage the differences between development and test environments as time went on. I found that this mostly because the DevOps (configuration management) tools are geared towards maintaining a perfect operational state based on strict server roles defined in the tool. While this approach was better than manual management of development and test environments it was still quite easy to have the configurations between environments drift apart over time and end up with the same issues mentioned above.

    So how does Docker help and what makes it better?

    • Uses a layered approach to dependency management, making the configuration of environments easier to maintain.
    • Provides various runtime options allowing the same image to be run in multiple ways without extra configuration.
    • Can use any or no DevOps tools to build up your Docker images reducing the learning curve across engineering.
    • Lightweight runtime makes running multiple Docker images on a single machine more feasible than with VMs.
    • Decoupled network and storage layers allows a single Docker image to be run on a single system or multiple systems easily.

    These features allow developers to run complex multi-service architectures on their laptops and with the same runtime images operations can support any number of load or availability scenarios with as many or as few systems as necessary. This combination of predictable dependency management and runtime flexibility is like having all the ease of a Heroku environment with the flexibility of AWS or Softlayer.

    Docker has many other impressive features, and few shortcomings, but in my opinion it’s a great framework to build your DevOps culture around as it makes maintaining a predictable production environment and a flexible development environment easy with one tool. Over my next few posts I’ll cover more specific examples of using Docker in development, test, and production environments. In the mean time visit the links below to read more about Docker and it’s growing ecosystem.

    Docker, Deis, Shipyard

     

  • Ops is dead, long live DevOps

    Ops is dead, long live DevOps

    Yes, that’s a bold statement, but if the vibe at the recent AWS re:Invent conference was any indication there are a number of methodologies, technologies, and companies working to make that a reality. This article isn’t focused on whether this is a good or bad thing (my personal belief is that ops will always be a critical part of the IT delivery process). Regardless, it is critical for IT operations personnel to understand the implications of this tectonic shift. As Marc Andreessen, founder of the venture capital firm Andreessen Horowitz, has said, “software is eating the world.” As a result, ops professionals must have the ability to automate tasks that used to be managed manually. Whether or not you think that is the death of ops as we know it I will leave to you, but it does mean we will live in a world where DevOps will offer distinct advantages.

    Before we dive into what this change means to ops personnel, let’s review the underlying assumptions. The fundamental driver at the a high level has been the DevOps movement. Yes, DevOps is quickly becoming the buzzword dejour, but the underlying principles are lasting and changing IT to its core. DevOps is about integrating the various functions that it takes to release software or applications: software development, quality assurance, operations, and security among many others and rapid iteration. The process of integrating these tasks is accomplished through new processes and automation. Different functional areas such as development and operations are brought into the process earlier, and their processes are automated to the extent that they can be. This results in fast cycle times, increased quality, and hopefully increased innovation for the business. All of this is accomplished through software – at each functional level.

    Some technologies that have enabled this massive shift include Infrastructure as a Service (IaaS), Platform as a Service (PaaS), automated configuration management, server management tools, virtualization, and software defined networking. IaaS and PaaS offerings are eliminating the need for organizations to procure, provision, and deploy servers. Further, this class of technology is also dramatically reducing the need to deal with the network layer. This allows organizations to concentrate on their applications and development, and focus less on their infrastructure. The amount of time and effort spent on server and network configuration is minimized. Configuration management solutions are enabling the automation of server setup. An organization’s technology stack can be pushed, pulled, cloned and copied versus manual configuration thereby saving time and adding consistency. Top performing organizations employing DevOps go a step further and automate the scaling of capacity based on utilization. To reduce day-to-day operational activities and costs, organizations are also automating the management of servers, including users access, patches, security, and other areas through both traditional written code and SaaS solutions. Another area changing the game for ops personnel is software defined networking (SDN), which is effectively morphing data center and hardware functions into software programs.

    In short, DevOps and associated innovative new technologies are driving a paradigm shift in the way operations is done. No longer are ops personnel required to manually provision, configure, and manage the network, servers, and application stack. Combining technologies from organizations such as AWS, Rackspace, and SoftLayer along with configuration tools such as Chef and Puppet drives the provisioning and configuration of applications through software automation rather than manual effort. Once applications are deployed, the underlying infrastructure can be managed with tools such as my own company, New Relic, this author’s own JumpCloud, and others. Ops personnel have more companies than ever focusing on helping them automate the tasks that they need to deliver applications for their organizations.

    The result from all of this effort is that ops as we know it won’t exist in the future. The network operations wizard that could manually troubleshoot routing and switching issues, provision servers quickly, and tweak configurations will be tasked with automating those tasks through software. Some of that automation will be through code that ops person writes herself, some delivered by third party providers, and other portions delivered by open source or SaaS-based solutions. But, don’t shed tears for the forced obsolescence of the IT ops people. They will still exist and perhaps be more important and powerful than ever. In fact, because of DevOps ops personnel will in essence be set free from mundane, repetitive “busy work” to perform higher value tasks as well as managing over the software and systems at work. The black magic of enabling different layers of the stack to function together will be less about art and more about science, or rather good software. Solutions will be engineered to work together and be tied together through code. Caveat: yes, service providers and some large enterprises will  still run their own data centers and networks, but the same reasons that DevOps works in IaaS or PaaS will apply to private data centers or private clouds as well.

    If all of this trends toward being true as we see it happening today, what are the opportunities for ops personnel to be at the forefront of this shift? Beyond embracing DevOps – which many operations personnel are doing already – learning to code is the most critical step that ops professionals can take. Many ops professionals already know how to script which is absolutely a minimum, but many will need to go further. Embrace the DevOps movement and push further towards the development side by learning how to code. There are any number of amazing services to teach us how to code or code better. Take the step. It may be the difference between a vestige of the old school versus driving the new world in your organization. The second significant step you can take is to automate your job. Leverage the very best automation tools to code your network, server, and application infrastructure. Not only will you spend less time on these tasks manually, but you will increase availability, reliability, and performance. In most organizations, that’s more than a gold star. Finally, make the mental shift that operations in the future will be less art and more science. DevOps is driving action through data, and the technology stack is responding to this demand with more telemetry than ever. Problems are now solved through understanding performance, availability, and other metrics. And code.

    DevOps is the future. Automation is key. Code is the answer. Developers and ops are in it together for the good of their organizations. Ops pros that embrace this will win! Ops is Dead, Long Live DevOps!

  • DOCKERCON 2014

    dockercon14

    Registration and call for papers are now open for DockerCon 2014!

    DockerCon is a two-day Docker-centric conference organized by the team at Docker Inc. We’ll have speakers talking about Docker, DevOps, operations and development. Our talks will include topics that will interest Developers, SysAdmins as well as C-level executives.

    The conference will start with general session with keynotes in the mornings, untill 11:00am, followed by three different tracks:

    • Docker University
    • Docker for Developers
    • Docker for Ops & Sysadmins

    Docker University will be the place to learn about using Docker, building Docker images as well as learning about the Docker API.

    In the Docker for Developers track, you will learn about Docker best practices, CI/CD, orchestration, Registry, Docker-core, real-life use cases and more.

    The Docker for Ops & Sysadmins track will introduce you to Docker performance, metrics, security, scaling and orchestration.

    DockerCon is also the occasion to meet with the Docker eco-system: contributors, developers, devops, ops, hackers, partners, and also the Docker team including Solomon Hykes (Founder) andBen Golub (CEO).

    We are also organizing a Docker Hackathon during the week-end prior to DockerCon. Winners will be able to present their project during the conference. Register here if you would like to participate.

    We invite you to follow the official twitter account: @DockerCon, in order to get the latest updates.

    Happy Hacking!

  • Red Hat Announces Certification for Containerized Applications, Extends Customer Confidence and Trust to the Cloud

    Red Hat Container Certification delivers secure, consistent and simplified platform for ISVs to take advantage of containers in Docker format

    RALEIGH, N.C., Mar 11, 2014 (BUSINESS WIRE) — Red Hat, Inc. RHT -0.84% , the world’s leading provider of open source solutions, today announced the extension of its application certification program to include containerized applications. The Red Hat Container Certification ensures that application containers built using Red Hat Enterprise Linux will operate seamlessly across certified container hosts. Designed with the needs of independent software vendors (ISVs), service providers and their enterprise customers in mind, the certification extends the confidence customers have with Red Hat Enterprise Linux, which currently supports thousands of certified applications, to certified containers running on certified container hosts. The pending release of Red Hat Enterprise Linux 7 and Red Hat’s OpenShift Platform-as-a-Service (PaaS) offering will both be certified container hosts, with Docker as a primary supported container format.

    Linux Containers

    Linux Containers have emerged as a key open source application packaging and delivery technology, combining lightweight application isolation with the flexibility of image-based deployment methods. Developers have rapidly embraced Linux Containers because they simplify and accelerate application deployment, while many PaaS platforms are built around Linux container technology, including OpenShift by Red Hat. Red Hat Enterprise Linux implements Linux Containers using core technologies such as Control Groups (cGroups), Resource Management, SELinux, and network namespaces, enabling secure multi-tenancy and reducing the potential for security exploits.

    Building on the capabilities of Red Hat Enterprise Linux, application containers are deployed as software packages that include the application and all of its required runtime components. Benefits include:

    • Instant portability , deploy the certified application container across any certified container host
    • Minimal footprint , avoid the overhead of virtual machine images which include a complete operating system
    • Simplified maintenance , reduce the effort and risk by patching applications along with all of their dependencies
    • Lowered development costs , develop, test and certify applications against a single runtime environment

    Red Hat Container Certification

    The Red Hat Container Certification is the latest addition to Red Hat’s industry-leading certification portfolio that includes Red Hat Enterprise Linux and Red Hat Enterprise Linux OpenStack Platform. The certification is also part of a larger set of Red Hat technology initiatives which in turn support thousands of third party technology partners within Red Hat’s global ecosystem

    To support this newly announced container certification, Red Hat is also announcing the container certification Partner Early Access Program (PEAP). The PEAP will run through late spring and provide the ability for ecosystem partners to participate in early testing, integration and feedback of the tools and resources required for containerization prior to the official launch of the certification and partner program, currently planned for mid-2014. Beginning today, companies interested in being part of the PEAP can learn more by visiting https://engage.redhat.com/content/enterprise-early-access-se-201402101640.

    Supporting Quotes

    Paul Cormier, president, Products and Technologies, Red Hat

    “Twelve years ago, Red Hat shook up the enterprise status quo with the introduction of Red Hat Enterprise Linux, a safe, consistent Linux platform for the ISV ecosystem. Today, the trust that ISVs place in Red Hat Enterprise Linux can extend to containerized applications with the Red Hat Container Certification, ensuring that containers built on Red Hat Enterprise Linux will work as intended across certified hosts, delivering expanded application flexibility, lowered costs and simplified maintenance, all backed by the support and expertise expected from Red Hat.”

    Ben Golub, CEO, Docker

    “As the de facto standard in open source container technology, we are pleased to see Red Hat embracing the container movement as a means of application efficiency and consistency across computing footprints. By offering a container certification on Red Hat Enterprise Linux and Docker, Red Hat is providing the industry’s only standardized, stable platform for commercial container workloads, providing a safe, reliable way to deliver the enterprise applications of the future.”

    Matt Asay, Vice President of Marketing and Business Development, MongoDB

    “Consistent with its mission of high value and affordability, Red Hat continues this trend through a supported platform that enables consistent enterprise-grade application deployment. We’re excited to work with Red Hat to provide customers a seamless database environment that is consistent from development to deployment, regardless of where it resides within the open hybrid cloud.”

    Connect with Red Hat

    About Red Hat, Inc.

    Red Hat is the world’s leading provider of open source software solutions, using a community-powered approach to reliable and high-performing cloud, Linux, middleware, storage and virtualization technologies. Red Hat also offers award-winning support, training, and consulting services. As the connective hub in a global network of enterprises, partners, and open source communities, Red Hat helps create relevant, innovative technologies that liberate resources for growth and prepare customers for the future of IT. Learn more at http://www.redhat.com .

    Forward-Looking Statements

    Certain statements contained in this press release may constitute “forward-looking statements” within the meaning of the Private Securities Litigation Reform Act of 1995. Forward-looking statements provide current expectations of future events based on certain assumptions and include any statement that does not directly relate to any historical or current fact. Actual results may differ materially from those indicated by such forward-looking statements as a result of various important factors, including: risks related to delays or reductions in information technology spending; the effects of industry consolidation; the ability of the Company to compete effectively; the integration of acquisitions and the ability to market successfully acquired technologies and products; uncertainty and adverse results in litigation and related settlements; the inability to adequately protect Company intellectual property and the potential for infringement or breach of license claims of or relating to third party intellectual property; the ability to deliver and stimulate demand for new products and technological innovations on a timely basis; risks related to data and information security vulnerabilities; ineffective management of, and control over, the Company’s growth and international operations; fluctuations in exchange rates; and changes in and a dependence on key personnel, as well as other factors contained in our most recent Quarterly Report on Form 10-Q (copies of which may be accessed through the Securities and Exchange Commission’s website at http://www.sec.gov ), including those found therein under the captions “Risk Factors” and “Management’s Discussion and Analysis of Financial Condition and Results of Operations.” In addition to these factors, actual future performance, outcomes, and results may differ materially because of more general factors including (without limitation) general industry and market conditions and growth rates, economic and political conditions, governmental and public policy changes and the impact of natural disasters such as earthquakes and floods. The forward-looking statements included in this press release represent the Company’s views as of the date of this press release and these views could change. However, while the Company may elect to update these forward-looking statements at some point in the future, the Company specifically disclaims any obligation to do so. These forward-looking statements should not be relied upon as representing the Company’s views as of any date subsequent to the date of this press release.

    Red Hat, Red Hat Enterprise Linux and the Shadowman logo are trademarks of Red Hat, Inc., registered in the U.S. and other countries.Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries.

    SOURCE: Red Hat, Inc.

    Red Hat, Inc.John Terrill, 571-421-8132 jterrill@redhat.com

    Copyright Business Wire 2014

  • DOCKER 0.9: INTRODUCING EXECUTION DRIVERS AND LIBCONTAINER

    From the Docker Blog:

    Fellow Dockers,

    Today we are happy to introduce Docker 0.9. With this release we are continuing our focus on quality over features, shrinking and stabilizing the core, and providing first-class support for all major operating systems.

    In addition to dozen of bugfixes, Docker 0.9 includes 2 major improvements: execution drivers andlibcontainer.

    As usual, for a complete list of improvements, you can check out the Changelog.

    Execution drivers

    First, we are introducing an execution driver API which can be used to customize the execution environment surrounding each container. This allows Docker to take advantage of the numerous isolation tools available, each with their particular tradeoffs and install base: OpenVZ, systemd-nspawn, libvirt-lxc, libvirt-sandbox, qemu/kvm, BSD Jails, Solaris Zones, and even good old chroot. This is in addition to LXC, which will continue to be available as a driver of its own.

    There are already several projects underway to develop more drivers. Want to join the fun? Come say hi on #docker-dev on Freenode, and we’ll help you get started.

     New default driver: libcontainer

    docker-execdriver-diagram

    Second, we are introducing a new built-in execution driver which is shipping alongside the LXC driver. This driver is based on libcontainer, a pure Go library which we developed to access the kernel’s container APIs directly, without any other dependencies.

    Thanks to libcontainer, Docker out of the box can now manipulate namespaces, control groups, capabilities, apparmor profiles, network interfaces and firewalling rules – all in a consistent and predictable way, and without depending on LXC or any other userland package. This drastically reduces the number of moving parts, and insulates Docker from the side-effects introduced across versions and distributions of LXC. In fact, libcontainer delivered such a boost to stability that we decided to make it the default. In other words, as of Docker 0.9, LXC is now optional. To switch back to the LXC driver, simply restart the Docker daemon with docker -d -e lxc. Of course we will continue to support the LXC driver going forward.

    Using libcontainer for your Go projects

    We have developed libcontainer in the hope that other projects will reuse it. If you’re interested in playing with the native container features of Linux – namespaces, cgroups, capabilities etc – then we encourage you to start hacking! To get started go get the Go package and check out the API docs:

     

    1
    2
    go get github.com/dotcloud/docker/pkg/libcontainer
    godoc github.com/dotcloud/docker/pkg/libcontainer

     Objective 1.0

    This release is a major step towards a stable, production-ready 1.0 release. We plan on making our next release, 0.10, the first release candidate for 1.0.

     As discussed previously, the goals for Docker 1.0 are:

    • production quality

    • first class support of all major operating systems

    • a shrunken core and a stable plug in architecture

    • well documented

    • able to be commercially supported by Docker and our partners

    • Docker able to offer long term support

    We are already hard at work preparing 0.10, with several exciting improvements that we think you will like. If you would like a sneak peek, or if you feel like contributing – come say hi! We are on #docker on Freenode. We welcome enthusiasts of all levels and can help you get started with your first contribution. As always, thanks go out to our community of contributors, now 352 strong!

    Thanks and happy hacking!

     

    The Docker team