DEVOPS

New Relic : Remove all not reporting Servers

Some infrastructure which I run spins up new Instances for Jobs and removes them afterwards. Because I still want to have some insights on what happened on the machine I installed NewRelic Server monitoring on the boxes.

As those instances fade away after each run i had quite a few servers listed (around 300-400) in there and New Relic still does not support Bulk removal of servers.

Thanks to Matt Weg,  who posted following Fix in the Discussion Groups of NewRelic which features a pretty easy one-liner for solivng this issue.

curl -X GET ‘https://api.newrelic.com/v2/servers.json’ \ -H “X-Api-Key:${NR_API_KEY}“ \ | jq -r ‘.servers | .[] | select(.reporting!=true) | .id’ \ | xargs -I % curl -X DELETE https://api.newrelic.com/v2/servers/%.json \ -H “X-Api-Key:${NR_API_KEY}“

To get this running on OSX i need to install jq (via Homebrew)

brew install jq

Speaking DevOps’ish Topics? Talk to me!

amsterdam_logo

When the year started to be really awesome with attending the DrupalDevDays in Szeged and lots of good work for TEDxBern. Next week will be DrupalCon Austin which I am really looking forward to.

Currently, sitting in the 22nd story at Time Square in New York and working on the DevOps track for DrupalCon Amsterdam is just an addition to the good things that happen this year!

So what is my role with DrupalCon Amsterdam?

I chair the DevOps Track together with my fellow co-chair, Kris Buytaert. This means we care about the sessions which will be submitted to the Track and we also try to get a diversity of good talks into our Track.

The call is on you now!

Are you passionate about sharing your experiences with the DevOps Culture? Did you achieve perfect testing results by automating everything so your biggest question you think about is if you should use rather vim or emacs?

Then you should consider talking about your experiences at DrupalCon Amsterdam!

To give you a hint which topics we like to see in our Track:

Culture

How did you establish DevOps within your organization? We like to hear about your success stories but also learnings you had on your way to establish a new culture.

Log Handling

How do you deal with your Logfiles? Are you visualizing them? Did you come up with a good way of putting this information to work for you and not being a burden to you?

Testing

How are your Tests doing today? How do you implement testing during project stages? And how did you start in testing your code?

Continuous Delivery

Do you deliver features continuously and you do not fail in any circumstance? Talk about this!

New Technology

Are you using new Technology which is on the rise and you use it to make the impossible look like it’s easy? Give yourself a go and submit 😉

Convinced? Submit here!

What do OPS teams need in the software you’re producing?

The Tweet from Bob has been “redirected” by Steve so I accept the challenge to loose some words about this topic.

The Initial Question was :

 

So what does a Operations Team (if you’re hipster enough you call it DEVOPS-Team) need in software wich has to be supported and maintained after the developing teams handed it over?

  1. DOC-U-MEN-TA-TION (refers to code comments *#thisisacomment or //thisisalsoacomment* and written documentation)
    Yes, this word stands for what we usually care the most. Immagine a team which hands over’s a huge project to another team without being allowed to talk or having a conversation about the product.
    IF the receiving team can pick up the work with minimal effort by just reading the documentation your team wrote you diserve an award!
  2. Monitoring
    After your beloved OPS Team has started to work on the project it’s common to monitor the system (usually even prior to product launch). I refer to #1 you should document it, how and what should be monitored.
  3. Core-Hacks
    I don’t want to loose many words about core hacks but if you hand over stuff to me and i see that you hacked the core… i’ll set you on fire. (editor’s note: sometime i loose my temper about this point…)
  4. Log Files
    Fun fact: OPS Teams never eat… they take their energy out of logfiles which are written to the production servers.
    Now seriously, if you encounter a exception in your application you should log this to a file.
  5. Stage and Live Systems
    Having a stage-system is sometimes a pain because you have to maintain your application two times. But hey if something went’s wrong you can fix the bug first on a cold system instead of fixing it on the hot production system. Some people love the thrill that comes with fixing bugs in a live system (i personally enjoy it – sometimes). But normally there should be a stage system.
    Side note : If you have important production systems there are sometimes not just a stage and a production system. There are two additional systems one for development and one additional for testing purposes.
  6. Understand what you do
    This point is intended to be a hint for developers. Working on cutting edge technology  is cool, but you should not focus just on your code you write you should also gain some knowledge about your newest shiny technology you use. It will not kill you and if it gets OPS-style just speak up and ask your friendly operations guy next door™. I write this point down because i’ve seen sometimes that dev’s use the newest technology and stuff without even caring for the technology itself. If someone gains access to your database/crm/backend be sure that he does not only type admin:admin as username password combination to get access to it, because nobody cared about reading the documentation of the technology you  use.
  7. Security
    Embrace security in everything you code and specify. It’s okay to be worried about security. This point relates directly to #6

These are just a few point’s that came across my mind after reading the Tweet from Bob. There are plenty more, just follow the advice of Bob and ask your Teams what they need. There is always a operations sight of the project and not just the customer point of view.