Containers
— ROELBOB
Category: Containers
-
Survey on Modern IT – We Need Your Opinion!
Change is the only constant in the world of IT. Developers, ITOps and the DevOps community are undergoing significant changes in needs, processes and services. This survey will provide better understanding of how the latest trends are impacting innovation, security and your team.
This survey is sponsored by Apcera, a highly secure, policy-driven platform that lets enterprises innovate at speed with full confidence and trust. You can learn more by reading an interview with Apcera CEO, Derek Collison, on Container Journal.
The survey is under 20 questions and takes about 5 minutes to complete. Share your thoughts on what is leading innovation, what stands in your way and how new technologies are are influencing the IT landscape.
By taking the survey, you’re helping the entire DevOps community better understand where we stand and where we’re headed. As always, the results will be released when the survey period is complete.
-
Creating Dev Environments With Docker Compose
The Slack notification popped up on my phone at 2pm Friday afternoon. “Argh. This is never good” I thought to myself. The message said “do you know anything about Vagrant?”. It was from a client of mine and I knew their environment well enough to know that this question was going to go down a rabbit hole the likes of which would leave Lewis Carroll awestruck. To compound matters, I was in the middle of nowhere, halfway between Las Vegas and Phoenix. I found a place to pull off, overlooking a vast, expansive maze of canyons and riverbeds leading nowhere and everywhere at once. I thought to myself “how fitting” as I started to reply on my phone.When launching a startup, there is no rule other than “find out what the
customer is willing to pay for, then build it”. My client, Roger, had nailed it. His next message confirmed this as I read “I’ve been beating my head against a wall for two days trying to get this Vagrant image running. I’ve got new developers starting next week and need to get them a dev environment setup”. Roger had just discovered startup rule #2: “nothing can prepare you for the panic of success”.
His current environment was very solid: running in AWS, everything was deployed via OpsWorks to both staging and production environments. It works great… if you’re the only one in staging. It wasn’t going to support multiple developers changing code simultaneously, so he was looking at Vagrant for a solution. Each developer needed mongodb, elasticsearch, redis, and two node.js servers: one for the api and one for the web ui. Vagrant images are great, but I’ve often found them to be most valuable when hand-curated, like craft beer. They are also difficult to share as it requires shuttling large vm images around between developers.After reviewing the error logs, I could tell he was facing issues with security permissions between the vagrant image and the host OS. I decided I wanted to try something different. I wanted to try building it out using Docker containers. I had a feeling I could accomplish the same results with Docker, plus the added benefits of the entire environment being stored as config files in a git repo. Small, concise, version controlled, portable… I was liking this idea more and more. I sold him on the idea as well as buying enough time to get back to civilization where I could work on the idea (though the overlooking view was pretty inspirational).
Back at the office, I broke open my laptop. I was familiar enough with Docker, but had a suspicion that Compose would help me tie the disparate pieces together. I started with the node.js servers. It was easy enough to kickstart them using a Dockerfile. (NOTE: I could have done this in compose as well, but had a feeling that I would want some extra flexibility later so I created separate Dockerfiles for them.)FROM: node:latest EXPOSE 3000
Next, I created the docker-compose.yml file to define the environment. I was able to define all of the containers (minus my previously created node.js servers) using images from Docker Hub.web: build: ./web ports: - “3000:3000" volumes: - ./code/web:/srv/www command: node /srv/www/server.js api: build: ./api ports: - "3000:3000" volumes: - ./code/api:/srv/www command: node /srv/www/server.js redis: image: redis mongodb: image: tutum/mongodb ports: - "27017:27017" environment: MONGODB_PASS: password elasticsearch: image: elasticsearch ports: - "9200:9200" - "9300:9300"
Once this was done, I created links in the web container. This creates environment variables and hostfile entries in the web container, allowing the web container to access the elasticsearch container via the hostname “elasticsearch”, and the mongodb container via the hostname “mongodb”, etc…links: - api - redis - mongodb - elasticsearch
The environment was complete, and I brought it up with the “docker-compose up” command. The added benefit of this environment is that the docker-compose terminal window maintains a steady stream of logs from all of the containers in a central window. This allows the developer to view the logs realtime, without having to hunt for them.
The only real stumbling block was in the use of VirtualBox. I created the environment on OS X. Since OS X can’t run Docker natively, it all runs in a VirtualBox machine on my workstation. This meant that I needed to go into VirtualBox and setup port forwarding for the required ports (3000, 3030, 27017, 9200, 9300,6379) so that I can access the services locally.Including time spent learning the basics of Compose, the entire environment was up in 2 hours. By using Docker, Roger’s new developers will be able to clone the config from a repo and be up and running in minutes regardless of whether they are developing on OS X, Windows, or Linux. Future additions to the repo can be shared by all by continuing to update the repo.Interested in trying it out for yourself? All the code described can be found in my git repo at https://github.com/rekibnikufesin/docker-compose. Be sure to let me know your thoughts in the comments or via twitter @wfbutton! -
DevOps, ITOps and PaaS: What do you think?
We are very happy to announce that we have launched a new survey that will explore how the community feels about DevOps, ITOps and PaaS. The survey is another in the continuing surveys we are conducting to help all of us understand more about how DevOps is really influencing how development, Ops and IT are being changed.
This survey is sponsored by Apcera, makers of the Apcera Hybrid Cloud OS. The survey is only about 19 questions and shouldn’t take more than 5 minutes. It is aimed at understanding if there is a difference in opinion of who is leading innovation and where are the roadblocks to that innovation in organizations. It also seeks to understand what are organizations are thinking about containers and specifically are different parts of the IT team looking at containers differently. Finally, the survey tries to help us understand what are the attitudes towards PaaS.
As we always do we will release the survey findings when complete. You are helping not only your own organization but the entire DevOps community if you would take a few minutes to take the survey right now we would be very grateful. If there is something you think we got wrong on the survey or left out, please let us know by commenting here.
If you are interested in hearing more about Apcera and how it looks at containers and PaaS you should check out our Q & A with their CEO over on Container Journal.
BTW stay tuned as next week we will release the results of our last survey, The Real Value of DevOps.
-
4 big challenges of microservices
The rise of microservices as a means of developing and delivering software value faster is clearly on the rise. Containers have skyrocketed from a fringe technology to a mainstream imperative and organizations are scrambling to jump on the microservices bandwagon. Before you rush out to embrace microservices, though, there are a few things you should keep in mind.
First let’s talk about what microservices even are since it’s a relatively new term in a sea of relatively new terms.
Al Hilwa, research director, Application Development Software at IDC described microservices this way:
“Microservices is an architectural approach that draws on long evolving experience in software engineering and system design, including the SOA efforts of the last two decades. Microservices architecture is enabled by a spectrum of tool categories but is primarily an architectural approach to system design that also requires considerable organizational and cultural adjustment to execute successfully.”
Put more succinctly, microservices is an evolution of software development and deployment that embraces DevOps and containers and breaks applications down to smaller individual components. Organizations can develop and deploy faster because there is a modular approach that makes code more efficient and enables much of the common or routine elements to be automated.
Everyone seems to be doing DevOps and containers these days. If you’re not you may feel like you need to catch up quick or risk being left in your competitors’ collective dust. That may be true to some extent, but you have to approach microservices in the right way and for the right reasons. Jinesh Parekh, CEO of Idyllic Software, shared some thoughts about four challenges organizations should consider when venturing into the world of microservices.
1. Insufficient guidance
When it comes to implementing new technologies and embracing new strategies it can be a little like the “Wild West”. There are few hard rules in place and very little in the way of guidelines or documentation to help you navigate how to build and deploy software using microservices. Thankfully, sites like devopsy.kinsta.cloud and ContainerJournal are here to provide as much information as possible to give organizations some guidance.
2. Getting it wrong
There are a variety of “moving parts” involved in doing microservices successfully. Your organization should adopt a DevOps culture and have the appropriate infrastructure in place to avoid getting it wrong. Microservices architecture is generally built on a foundation of cloud and virtualization, and relies heavily on automation to ensure success and avoid failures.
3. No going back
You should be aware that it’s exceptionally difficult to switch back once you start down the microservices path. The changes that have to happen in terms of culture, tools, and processes to embrace microservices are not easily undone. The good news is that there is very little—if any—reason an organization would move to DevOps and containers as a development framework and then decide to revert to the old, monolithic way of doing things.
4. Deliver value
Parekh’s focus on delivering value is biased toward Idyllic Software. His company is in the business of delivering applications for clients via microservices and Parekh suggests that organizations outsource development to an experienced leader to ensure microservices meets expectations. You don’t necessarily have to outsource to Idyllic Software, though, or outsource at all. You just need to make sure that your approach to microservices benefits your organization—that it adds value and meshes with business objectives and isn’t just microservices for the sake of following the microservices trend.
Microservices seems to be here to stay, and seems to be on the same path as DevOps and containers from niche concept to mainstream business adoption. As you ramp up to jump on the microservices bandwagon just make sure you keep these things in mind.
-
Microsoft and Docker provide progress report on Docker for Windows Server
In the fall of 2014 Microsoft and Docker unveiled a new partnership—a commitment to work together to bring native support for Docker containers to the next major release of Windows Server. Earlier this week the two talked about the progress made so far and gave some clues to what customers should expect once the next Windows Server hits the street sometime in 2016.
Mark Russinovich, CTO of Microsoft Azure, was in San Francisco this week at Docker headquarters meeting with his counterpart, Docker founder and CTO Solomon Hykes. The two met to talk about how their collaboration is progressing to bring Docker containers to Windows Server. The two didn’t share many specifics, but did say that the effort so far is achieving established goals and is proceeding according to the schedule they’ve laid out.
What is that schedule? We don’t really know. All Russinovich or Microsoft will commit to officially at this point is 2016. Whenever it arrives, though, it will represent a significant step forward in creating a platform-agnostic environment for developers. Windows developers will be able to integrate Docker containers natively with Windows Server, Visual Studio, and .NET applications.
The CTOs clarified that Docker support in Windows Server won’t allow Linux applications to run on a Windows operating system. Likewise, Windows applications in Docker containers won’t run on Linux. The value of the partnership and the integration of Docker support in Windows server is that developers will be able to leverage the same tools and common platforms for deploying, running, and managing the Docker container environment.
Microsoft Azure already added support for running Docker containers on Linux servers within the cloud platform. Once the new Windows Server hits, organizations will be able to run Docker containers on Linux or Windows and manage it all through Azure. It also enables developers to create application services running on opposing platforms and run it as part of a distributed application spanning both Windows and Linux.
The advantage from a Windows developer point of view is the ability to use the tools they’re familiar with. Developers will be able to use Visual Studio and .NET along with the built-in collaboration and workflow tools, as well as debugging and source-code control. It allows organizations to employ existing development practices and tools for creating and deploying Docker containers.
From a DevOps perspective the integration of Docker containers natively with Windows Server will enable better automation and continuity. DevOps and containers result in frequent changes to the app code and the underlying infrastructure, which is a bit of a culture shock for both traditional developers and traditional IT admins. Straddling the line between the two worlds by incorporating Docker containers and DevOps tools with the familiar Microsoft development platforms organizations are comfortable with takes some of the pain out of that cultural evolution.
Ultimately, the partnership between Docker and Microsoft will lay the foundation for completely platform-agnostic development. The app containers themselves may still require a specific OS to run, but at an organizational level the environment and infrastructure can be viewed and maintained as a holistic whole.
-
DevOpsQA NJ Meetup – Containers with Joyent
De
vOpsQA NJ just held our July Meetup on Containers with Casey Bisson from Joyent and Jeremy Rampon from Syncsort as speakers. The meetup was held at a new ROKITT location, a state-of-the-art office space with breathtaking views of NYC. This session marked 1 year since our Meetup was formed in July of 2014 and it was great to celebrate it with a great group of fellow DevOps and Automation enthusiasts.Jeremy R
ampon gave a great introduction to Docker and container technology. He spoke about how Docker allows to build, ship and run any app, anywhere with almost no overhead. We also discussed how Container technology is different from VM and future plans of Docker on Windows.Casey Bisson gave a b
rief overview of the Joyent technology which offers container native infrastructure that runs in public and private cloud. We all want to run Docker on bare metal, but don’t want to lose security and elasticity. Joyent provides a way to do this without the overhead attributed to VMs. The Triton Elastic Container Infrastructure is build on top of SmartOS and provides its implementation of the Docker API, with full support for the Docker client and related orchestration tools. The advantages are the ease of management and improved performance from running on bare metal. We also got a live demo of the software that runs SmartDataCenter (software that runs the Joyent public sloud and powers private clouds) all the way from install to provisioning customer containers.At the end of the session we did a raffle for 3 awesome books sponsored by Pearson and then toasted to 1 year Anniversary of DevOpsQA NJ.
-
Microservices define the next era of IT
There is a lot of focus on DevOps and container technologies these days. Both are very strong trends in IT on their own, but each is also proof of a larger shift in IT culture to a microservices architecture. A new report from IDC titled “The Emergence of Microservices as a New Architectural Approach to Building New Software Systems” takes a closer look at the evolution and impact of microservices.
Let’s start with the obvious question: What exactly is microservices? “Microservices is an architectural approach that draws on long evolving experience in software engineering and system design, including the SOA efforts of the last two decades,” said Al Hilwa, research director, Application Development Software at IDC. “Microservices architecture is enabled by a spectrum of tools categories but is primarily an architectural approach to system design that also requires considerable organizational and cultural adjustment to execute successfully.”
Put another way, microservices is an umbrella term that applies to breaking systems and applications down to a more granular, modular level. Containers are an example of taking an application and making it into a self-contained component, and DevOps provides the framework for developing, deploying, and managing the container ecosystem.
By some interpretations microservices and containers are somewhat synonymous. In other words, microservices is just another way of saying that an organization is using container technologies for app development and deployment. IDC classifies microservices more broadly, saying it is based on an approach to organizing software development—more of a concept and less of an actual product or technology.
The Wikipedia definition of microservices sums it up like this: “In computing, microservices is a software architecture style, in which complex applications are composed of small, independent processes communicating with each other using language-agnostic APIs. These services are small, highly decoupled and focus on doing a small task.”
Although the concept of microservices is broader than the underlying platforms or tools it uses, IDC acknowledges that the advancements in software development and deployment methodologies—namely DevOps and container technologies—has played a pivotal role in elevating microservices to where it is today.
The transition from a traditional hardware server infrastructure in an on-premise datacenter to a cloud-based, software-defined infrastructure that can be created, modified, or removed programmatically offers significant benefits for organizations. The microservices architecture enables companies to be much more agile and cut costs at the same time.
There are some challenges and concerns as well, though. Hilwa notes, “Microservices architecture, by its very nature, is distributed and operates across networks and can thus exact significant performance penalties that must be accommodated with architectural solutions, like caching layers and API management and optimization techniques.”
In the IDC report Hilwa talks about the need for strong organizational support and an overall shift in the IT culture in order to succeed with microservices. As Hilwa puts it, “Organizations have to increase their tolerance for risk and learn to fail gracefully, fast and often in order to achieve success.”
Hilwa provides a comprehensive overview of the current state of microservices in the report along with some prescriptive guidance for organizations that are either just trying to understand what microservices is, or those that have already waded into microservices but want a better appreciation for the benefits and pitfalls.
-
Webinar: Introducing CloudBees Jenkins Platform – your foundation for DevOps and CD with Docker Containers
Continuous delivery (CD) of applications is rapidly becoming a differentiator in this application economy. CloudBees, the enterprise Jenkins company, recently announced the availability of the CloudBees Jenkins Platform to help organizations adopt CD. This new enterprise offering from CloudBees brings CD to the masses with the new Team Edition, while enabling enterprise CD deployments powered by Jenkins at scale with the Enterprise Edition. At the same time, the Jenkins open source community, in conjunction with CloudBees, released six new plugins to support the use of Docker containers within Jenkins-powered CD and CI processes. Docker is powerful new technology that allows teams focused on delivering software to standardize their development and production application environments for reduced risk and accelerated application delivery. Leveraging Docker containers in a CD process managed by Jenkins is the ultimate way to deliver better software faster.
Join Tracy from CloudBees as she talks about Cloudbees’ new enterprise offering and the changes happening in the Jenkins community to provide first class support for Docker in the creation of CD pipelines. In this webinar, Tracy will introduce features in the latest release of the CloudBees Jenkins Platform to
help manage Jenkins’ across the organization and walk through six common delivery patterns with Jenkins and Docker. Tracy will then tie it all together with a demo of an end-to-end delivery pipeline with Docker.Continuous delivery with Jenkins and application containerization with Docker are rapidly becoming two of the foundations of the DevOps movement. Check out this webinar to learn how you can adopt these new tools and techniques in your own DevOps transformation.
Recorded: Wednesday, August 5th, 2015
Recording
Slides
[seoslides embed_id=”3285347f9c95″ script_src=”https://devopsy.kinsta.cloud/embed-script/cloudbees-jenkins/8856/” overview_src=”https://devopsy.kinsta.cloud/slides/cloudbees-jenkins/” site_src=”https://devopsy.kinsta.cloud” site_title=”devopsy.kinsta.cloud” title=”Cloudbees – Jenkins” /]
Your Host
Alan Shimel, Editor-in-Chief devopsy.kinsta.cloud, An often-cited personality in the security and technology community and a sought-after speaker at industry and government events, Alan has helped build several successful technology companies by combining a strong business background with a deep knowledge of technology.About the Panelists
Tracy Kennedy is an associate product manager for CloudBees and is based in Richmond, Virginia. Prior to her current role, Tracy has worked at CloudBees as a solutions architect and a developer success engineer. In her free time, she enjoys rock climbing, grand strategy games, and reading. Read more about Tracy in her Meet the Bees blog post and follow her on Twitter.
Udaypal Aarkoti is the Director of Solution Architecture at CloudBees. He believes in complete end to end automation and that continuous delivery is the future of application delivery. Prior to CloudBees he lead the middleware solution architecture team at Red Hat. -
Say hello to Container Journal
Today we launched a sister site to devopsy.kinsta.cloud – Container Journal. The url for the site is http://www.containerjournal.com. The site is dedicated to spotlighting everything about containers and computing (as opposed to containers like in the Container Store). This includes not only the containers themselves, but everything that goes along with it. Topics wil include container management, data management for containers, container security, networking for containers – in short the entire container ecosystem.
Right now most of the content on Container Journal was container related content that was originally on devopsy.kinsta.cloud. However, over time Container Journal will have more and more of its own original content that will not appear here devopsy.kinsta.cloud. So you will need to check Container Journal to stay up on the latest container related content. A good way of doing that is to sign up for the Container Journal newsletter.
In addition to articles Container Journal will feature webinars on container related topics, as well as other special features including ebooks and surveys. Many of the outstanding authors who contribute to devopsy.kinsta.cloud will also be writing for Container Journal as well.
We are looking for good container related content though. If you would like to contribute to Container Journal, write me at editor@devops.com with your request. We are also seeking sponsors, partners and advertisers for Container Journal as well. In a relatively short time, we think Container Journal will be largest media site with a dedicated collection of container related content. This is your chance to be part of it. Sponsor info can be had at sponsor@devops.com.
Also be sure to check out the Daily Poll on Container Journal. We will be asking some great questions with rapid feedback on what others are saying.
Like any new venture, I am sure there will be growing pains with Container Journal. Please keep me posted if you notice anything.
