GET EMAIL UPDATES FROM POWERTOFLY
By signing up you accept the Terms of Service and Privacy Policy
BROWSE CATEGORIES
GET EMAIL UPDATES FROM POWERTOFLY
Tech Talk

Continuous Deployment for Docker: Lessons Learned

First Hand Experience on the Path to Continuous Deployment for Docker Containers

Authors note: this is a summary of my session at DevOps Summit NY on June 8, 2017. For details on the session along with slides, visithttp://datagridsys.com/nomorescripts.

Being experienced startup folks we are not scared of bleeding edge tech. For instance, in 2005 we made the jump to virtual machines when most companies hadn't even heard of virtualization, in order to create our cloud platform, AppLogic. This time around we were already very familiar with containers, including many of the limitations, and believed they offered a lot of advantages in speed and cost so we decided to go with Docker running on AWS.

Our engineers have written a lot of apps including both interactive user apps and infrastructure level services and we're pretty adept at creating stateless systems where that's possible. Unfortunately, some of the third party software we needed to use, especially open source, wasn't written with stateless in mind.

For us combining Dev and Ops wasn't a choice, but a necessity. We couldn't afford another hire to run ops. Nonetheless we're fanatics for DevOps and automating everything we can in build, test and deploy. In our case the role of the DevOps guru fell on Pavel, one of our senior engineers. He's well versed in systems architecture as well as most of the systems that needed to be touched by the automation.

Introducing VCTR

The app we were bringing out is called Victor (VCTR for Vulnerabilities and Configuration Tracking and Reporting), a free online service that scans containers and VMs for upgrades that fix critical vulnerabilities. You can check out VCTR here.

As we progressed through development some things worked exceptionally well. New tools including Slack made collaboration among a dispersed team very easy. Build and test tools including Jenkins worked as expected though they were a bit harder to set up than they should be. Docker, despite some minor issues, was more mature than we expected. As you probably have guessed, though, there's a "however" coming. In our case, that "however" was that deployments were still complicated and error prone.

As we got started our deployment was managed part-time by Pavel, our senior engineer. After all, the literature available suggested he'd just be writing a few short pipeline scripts. At first this worked great, but since change is inevitable, things got complicated. VCTR began expanding as new features were integrated and Pavel's day job became wrangling an unruly set of deployment scripts. Of course, as he spent time on deployment he wasn't contributing to building VCTR. As Pavel got sucked further and further into script hell with each new change, he noticed he'd fallen into a pattern:

  1. understand changes -> understand current app -> write script
  2. test script -> debug -> deploy
  3. fail -> debug again -> redeploy
  4. manual rollback...
  5. give up

The options were minimal. Either we continue to fail through this deployment until we got it right, or find another solution to the problem

Deployment Pain

Despite deployment issues hindering our velocity we needed to push forward with VCTR so we started user engagement while looking for solutions. We assumed we'd find a new tool or pattern in time, but things took an unexpected turn. While implementing VCTR we found other folks having similar deployment issues. Bringing up a new user with VCTR requires installing a small piece of code in the container or VM. That process, not surprisingly, happens in a deployment script and in most cases inserting that one change caused a failure in deployment. In one instance, while on a video call with a user, we watched as a five minute change to one script turned into a two hour debugging marathon involving more than half a dozen scripts. The only folks who didn't have errors after making the change had actually recognized deployment as a significant issue and built their own system for it. Systems, so significant in the amount of time they took to build that they were given names and teams to maintain them. However, those systems were tied to their company's specific architecture and tool chain.

The heart of the problem is that despite articles to the contrary, containers and microservices have dependencies. Some dependencies are simple. For instance, some software still have start order dependencies. Others require configuration differences based on the environment they're running in. Still other require logging in and executing commands after startup. Some dependencies you create yourself. As an example, changing an API requires updates to both the providing and calling services. You might require all updates to be backward compatible, but that's just moving the work to what may be an even more complicated arena. Lastly, what happens when something fails? How do you find out what failed? How do you get back to a functional state?

Despite mounting evidence we didn't initially recognize the pattern. One day over lunch, as the discussion turned from VCTR to deployment issues we realized we'd seen similar problems before when we first tackled cloud deployment. Furthermore, we knew we could solve this. We decided to build a continuous deployment system.

Lessons Learned

We obviously learned a ton about what not to do when setting up a new containerized application. Here's our conclusion of the good and bad of containers, microservices and DevOps:

The good

  • Containers, though not perfect, have a rich enough ecosystem of tools to be used in production.
  • Microservices architectures are great but don't try to make everything stateless.
  • DevOps is the new norm, but you need to go beyond just assigning an engineer the title or merging the folks onto a single team. Ops must take on a new role defining use cases and Dev must embrace Ops.
  • Get your tool chain in place from the start. We tried to hack our deployments and as such didn't see the problem for what it was until we were knee deep in it.

The bad

  • Deployment remains hard because it's where software meets the real world.
  • Deployment requires a system once you get past a few containers. If you don't adopt one, you're going to end up building one - whether you realize it or not.
  • Scripts work fine for small apps that don't get updated often, but aren't up to the task for continuous deployment for apps that contain more than a few containers or microservices, especially those that are updated frequently.

The Result - Continuous Deployment System

We identified key challenge patterns that both ourselves and others faced during deployment and turned them into solutions. One important difference to the other deployment systems we had seen was that we made sure to build for varied environments and architectures. We didn't want this tool to just work for us or rather just the current pattern we were working in. We needed a true system to grow with us. Here are some of the main requirements of our Continuous Deployment system:

  • Integrate with popular tool chain elements
  • Recognize code and architecture updates
  • Provide for identifying dependencies
  • Provide for various operating environments
  • Automatically deploy authorized updates to operating environments
  • Automatically correct for common errors to return proper operation
  • Provide meaningful logs and error messages
  • Be operable from either UI, API or completely autonomously

We built this deployment system and it's now deploying VCTR on a regular basis. It's also in production at InnoScale and being tested by a handful of DevOps teams who felt the same pain as we did. We're offering the system for free to teams for up to 15 containers.

To learn more about Skopos - our continuous deployment system visit http://datagridsys.com/skopos/.

Originally article on Ulitzer


popular

How These Companies Are Celebrating Asian American and Pacific Islander Heritage Month

According to a recent study, anti-Asian hate crimes have risen 150% since the pandemic started. But these acts of violence are not new — they are part of a much larger history of anti-Asian racism and violence in the U.S.

That makes celebrating Asian American and Pacific Islander Heritage Month (which was named a month-long celebration in May by Congress in 1992 "to coincide with two important milestones in Asian/Pacific American history: the arrival in the United States of the first Japanese immigrants on May 7, 1843 and contributions of Chinese workers to the building of the transcontinental railroad, completed May 10, 1869") this year all the more important.

READ MORE AND DISCUSS Show less
Autodesk, Inc.

How Embracing What She Doesn’t Know Led Autodesk’s Arezoo Riahi to a Fulfilling Career in DEI

Arezoo Riahi isn't a big fan of the "fake it till you make it" approach. She'd rather ask for the help she needs and learn from it.

Autodesk's Director of Diversity and Belonging joined the design software company from the nonprofit world after a long career in connecting people from different cultures. While her work had been deeply rooted in DEI values, there were certain parts of the strategy-building aspects to her new role that she wasn't sure about.

"If you know it, show up like you know it. If you don't know it, you shouldn't fake it. And Autodesk didn't shame me for not knowing everything. They helped me, and the entire team, by providing the resources that we needed, bringing in outside expertise to help teach us when we were in new territory," says Arezoo, who has been at Autodesk for three years now, during which she's been promoted twice into her current role.

We sat down with Arezoo to hear more about her path into DEI work, what she thinks the future of that work must include, and what advice she has for women looking to build fulfilling careers, from knowing what you don't know and beyond.

READ MORE AND DISCUSS Show less
Videos

Behind-the-Scenes: Sales Interview Process at LogMeIn

Get an inside look at the interview process for sales roles at LogMeIn, one of the largest SaaS companies providing remote work technology, from Michael Gagnon, Senior Manager of Corporate Account Executive Sales.

READ MORE AND DISCUSS Show less
Procore Technologies Inc

How Being an Open Member of the LGBTQIA+ Community Has Helped Procore’s Alex Zinik Overcome Imposter Syndrome at Work

Alex Zinik wasn't surprised that she started her career in education—she decided she would become a teacher when she was just in third grade.

She was surprised while working as a paraeducator in the school system and preparing to become a special education teacher, she discovered that it didn't feel quite right. "I didn't know if that's what I really wanted to do," she recalls.

So a friend suggested she take a job during her off summers at construction software company Procore. She thought this would be the perfect opportunity to try out this new challenge, and if she needed to, she could go back to the school district once the summer was over.

"Five summers later, I'm still here!" she says, smiling. "And I see myself here for many more years. I just fell in love with the company, the culture, and with the career growth opportunities I was presented with."

As part of our Pride month celebrations, Alex, currently the Senior Executive Assistant to the CEO at Procore, sat down with us to share how a common fear—the fear of being found out—underlay the imposter syndrome she felt when pivoting to an industry in which she lacked experience, and the anxiety she often felt before coming out to her friends and family about her sexuality.

Read on for her insight on overcoming negative thought patterns, being yourself, and paying it forward.

READ MORE AND DISCUSS Show less
CSL

The Outlook That Helps CSL’s Paula Manchester Invest in Herself and Her Team

If you told Paula Manchester that you weren't good at math, she wouldn't believe you.

"That's a global indictment," she says. "'I'm not good at math' implies that you don't have the ability to nurture that muscle. And then I'd ask what kind of math? There's a lot to math."

READ MORE AND DISCUSS Show less
© Rebelmouse 2020