DZone
DevOps Zone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > DevOps Zone > Unleash the DevOps!

Unleash the DevOps!

Instead of reconfiguring whatever is in charge of baking new servers every time configuration has changed, why not throw it away and spin up a new one?

Baruch Sadogursky user avatar by
Baruch Sadogursky
·
Mar. 15, 17 · DevOps Zone · Opinion
Like (3)
Save
Tweet
4.15K Views

Join the DZone community and get the full member experience.

Join For Free

DevOps tools have come a long way from virtual machines in dev and QA environments to those in production, and now Docker. The more we are charmed by the idea of hardware as a code, the crazier the things we are trying to do with it. Take the immutable server pattern as an example.

In 2000, how crazy was the idea of throwing away a perfectly good server because the configuration changed?! Today, we understand that state changes are not maintainable; they are the root of all evil, and (thanks to hardware as code) throwing the server away instead of changing it is the right way to go.

But how about an immutable data center? I mean, why not? It’s the next logical step, isn’t it? Instead of reconfiguring whatever is in charge of baking new servers every time configuration has changed (I mean the CI server, the artifact repository, and the provisioning server), why not throw it away and spin up a new one? 

DevOps Tools - Immutable Server Lifecycle

Source.

Now, starting with Artifactory 5, you can! It can be completely automated by robots; not only basic operation (we always knew that 95% of the interaction with Artifactory is done by robots) but also provisioning, configuration, and decommissioning. A cluster of Artifactory servers can be spun up (including license pool management), configured with the right repositories, configuration, and permissions, elastically scaled, and then killed when this data center is destroyed instead of being changed (and the licenses will return to the pool to be reused).

So, here’s what it takes to fully configure Artifactory with a valid license, custom base URL, reverse proxy for Docker support, and fully configured set of repositories for Docker, NPM, Maven, and RPM.

How do you put this beauty to use? By spinning up an Artifactory server, complete with database, NGINX and the whole shebang using Docker Compose (or start Artifactory in any other way) with this YAML file in your $ARTIFACTORY_HOME/etc folder. Cool? Uber cool!

Talking about permissions and security, as Artifactory is managed by robots instead of people more and more, user management no longer makes sense. Robots don’t have email addresses and can’t login to their profile to change their passwords. Usernames and passwords are the past; access tokens are the future. They are flexible enough to contain all the permission information, providing the right access to the right resource; they are expirable by usage and/or by time, and they are created, managed, and destroyed for robots by other robots. How cool is that (and a bit freaky, too)?

Back to DevOps tools and the proliferation of hardware as code, two of the main players in that market are Chef and Puppet. Their cookbooks and modules, respectively, are the code that creates the servers and complete datacenters that we spoke about. DevOps Tools: Chef vs PuppetThey are part of our pipeline for delivering those datacenters with servers in them, and as part of the pipelines, they have to be associated with the other parts of the pipeline — for example, which server is created by a specific cookbook. Changes in cookbooks create changes in servers, but other changes are usually added in, as well. How do you correlate between a new version of a JAR file, which comes from the Java build part of the pipeline with a new version of the JDK this JAR file is compatible with, that comes from the cookbook?

Bringing all those parts of the pipeline to a single tool provides the ability to annotate them with referenceable metadata. With Artifactory 5.1 and its support for Chef cookbooks and Puppet modules, you can mark a module that sets up a server with that new version of JDK as being compatible with the java build that produced that jar file that requires this JDK version.

And then comes the magic: you can search for them. Using Artifactory Query Language, you can now spin off a datacenter that has the correctly configured CI server (the slaves have the correct JVM version), the correctly configured artifact repository (all the repositories are preconfigured, and the right access tokens are generated), and the correctly configured servers for each stage of the pipeline — again, with the correctly generated servers with the right JVM version, all that just by using the right Puppet modules or Chef cookbooks.

Image title

How do you know which modules are right? By querying Artifactory to give you the right files (modules, cookbooks, docker images and application files) based on the target environment.

Is that DevOps on steroids, or what?!

DevOps

Published at DZone with permission of Baruch Sadogursky, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Top 7 Features in Jakarta EE 10 Release
  • Is DataOps the Future of the Modern Data Stack?
  • Modern Application Security Requires Defense in Depth
  • Applying Domain-Driven Design Principles to Microservice Architectures

Comments

DevOps Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends:

DZone.com is powered by 

AnswerHub logo