Mantle is a Go utility that wraps the POST process to Mesosphere’s Marathon API. Before, users had to store JSON with cleartext environment variables for their Docker container configuration. With Mantle, users can encrypt the values for the “env” parameters passed to Marathon using asynchronous public/private key pairs. Mantle is designed to allow operations or deployment teams to build user-level key pairs, and give those public keys to the users with the most knowledge of the application’s configuration. Those users, can then encrypt the JSON with Mantle via their public keys and let the deployment team review the JSON and have the final private key to decrypt and deploy to Marathon(s) via Mantle.
Like most operations teams, at SRC:CLR we’re offloading our logs to an aggregated log solution. We use the popular ELK (Elasticsearch, Logstash, Kibana). I love this solution but when it comes to simply copying and pasting log data from Kibana things get messy. When our developers need to get data quickly it would be easier to have a CLI utility that can do the same queries than having to open a browser and screen grab from Kibana.
Many tools exist to help automate and orchestrate provisioning servers. Each tool serves a purpose, or is tailored for a specific task. One realization I had not to long ago was that configuration management tools, as a framework, suck at provisioning micro services. I say that at the risk of bringing on the deluge of comments that often accompany such a blunt, over arching statement.
”…but does is scale?”
When it comes to micro-service architectures that’s always the big question. You can maintain a solid agile development process, design a micro service architecture, and implement seamless CI to ensure developers can launch code from their local test environment into Prod, but if you can’t respond to the increase in demand for your product then who cares? Unusable products, no matter how cool, won’t get traffic and your company will suffer.
Spring is a Java framework that has been around for the better part of a decade. Though some argue it’s growing long in the tooth, it’s still a standard among large enterprise to smaller startup style web applications. Spring boot is Spring’s answer to next generation, easy-to-implement, spring setup. Spring boot has a host of advantages over its legacy counterpart; chef for packaging up your application in jar file format vs. war file format, embedded tomcat, and the primary topic of this post: resource configuration based on config files found in the classpath.
I learned early on in my career that the trick to successfully maintaining large, complicated deployments was to make things so that they are like a factory, then solve your problems using factory patterns. The metaphor is extended from the continuous integration pipelines I develop for seamless code deploys to the ways in which I go about maintaining the infrastructure on which that code runs.
At SRC:CLR we used to use Opsworks to deploy our code pipeline. Opsworks is great but is overloaded with a lot of extra things that we don’t need or want. It also doesn’t allow us to fully open our code pipeline to outside applications in the way we wanted.
In order to give our devs the easiest way to deployment, we setup a pipeline from merge-to-master to deploy that encompasses the peer review process, java unit tests, and of course Puppet.
What’s the first line of action when dealing with a service that is down? Logs.
netstat aux all day long but the big piece of information cake always lies in the log data. Log data carries the weight of information about your services, whether it’s a Spring Boot micro service powering a small piece of your backend platform or the NGINX and auth logs that convey what is happening on the opposite end of your application stack.
Whatever the situation may be, logs are always the files we end up tailing to figure out what is happening and why.