DevOps

A while back I had done a round up of a few container scanning solutions and had mentioned I wanted to take another look at Anchore. The past few days, I’ve been playing a bit with Anchore - this time, integrating it with Drone CI. Drone is a “Container-Native, Continuous Delivery Platform” built using Go. It makes use of a YAML file, .drone.yml to define and execute the pipeline. End Goal # For this project, we will be integrating Drone and Anchore.

I recently published couple of articles elsewhere: How to Increase Container Security and Ward Off Threats - Adobe Tech Blog 5 OpenSource tools for container security - OpenSource.com Scanning Docker Images for Vulnerabilities with Aqua Microscanner - previously, on my blog Do give them a read.

Containers are slowly becoming the standardized units of deployment. As containers become more popular, they also become the focus targets for attacking the system via vulnerabilities present in the packages within the image. There are quite a few container vulnerability scanning solutions (example: Clair, Twistlock, now Prisma Cloud, Aqua – however most of them are either commercial or require an elaborate setup, which makes it difficult for individual developers to involve them as part of the container build process.

In Chef parlance, databags are global variables saved in JSON format and are stored and accessible on the Chef server. Given that these are indexed and can be searched up along with the fact that they can be encrypted make them ideal candidates to store secrets such as credentials/ssh keys. Chef provides an easy way to search and fetch databag and databag items from within a recipe: For ex to fetch a databag called admins, it’s as easy as:

Among the services I look after, the biggest and high-profile - is the user facing website. The website is your bog-standard typical frontend(powered by Express/Angular) which fetches data via an API which is powered by the backend(built on Rails). Typical flow is that Express receives the request from the browser, makes a request to the backend which is then served using Rails API via nginx which acts as the reverse proxy.

Last night as I was about to head to sleep, Sensu started emailing me about disk space warnings on one of the backend servers. That’s strange, I thought. I had set up logrotate with appropriate limits to ensure the log file size is reasonable and rotation happens on a daily basis. Curious, I ssh’d into the server to investigate. Running a df -h indicated as expected the disk space in use was over 70% (which is the trigger for sensu to send a notification) and the log files had grown way over expected size.

I like chef-zero a lot. There’s so much overlap between chef’s products: chef-zero, chef-solo, chef-apply - yes, each have their own uses, but I digress. Chef-zero has been relatively pain-free for me - except when I tried to get it running - trying to figure out why it wasn’t fetching the cookbooks was so annoying! I went and RTFM couple of times, no dice. Then I decided to not skim read and read the entire thing.

I have begun to use Terminator quite a lot. Terminator’s quite handy when you want to connect to multiple servers on a single terminal thanks to its split pane feature. (And yes I know about tmux & screen - I have screen on my servers, don’t want to get into the headache that is nested screen panes). Few days back we were preparing for a big migration & deploy and I was tasked upon to prepare a failover just in case the migration goes wrong.