can you tell us how is different from the jenkins box
Basically its a plain vanilla Jenkins box where we have a little bit more control of versioning, packaging etc. We needed a box that we developed, which would reside in our repo, to be used in our Infra as Code projects, DevOps workshops etc. so we wrote that one.
For example, there are other projects that take this box, then auto-configure Jenkins on top of it. So that Jenkins box acts as a base box for other projects, makes sense?
ubuntu1604-baseright? We could have used the box from vagrantup.com but again, we needed a measure of control over what goes into our base box. Hence a custom Ubuntu box.
anyone get a chance to look at the vagrant boxes?
vagrant-toolchains: Git repository with reusable DevOps environments
Even though it's early days yet, I thought I'd point you guys out to this repo we have been working on:
Often I have encountered situations where I need a quick easy-to-create DevOps environment on my machine, that just works without any fuss. Several of my colleagues in recent assignments expressed the same need. As a result, we started working on these vagrant-based environments.
In case you don't know what Vagrant is, this is a good document. We are working on some getting-started videos and docs in the mean time.
Check out the repository and let me know if you need help figuring things out.
@apoorv007 an interesting thought -- since the cause is rarely one tool it makes sense to do this. OTMH I'm thinking of some smart visualization on the kibana side (assuming ELK here of course).
That could work. I am wondering what would be the size of a bucket of tools with the same tag? Too big or too small would imply noise. How often it would change; will it be a maintenance nightmare as the infra scales?
I think the monitoring tools are better positioned to do such a batching since they have the information of which service is interacting at what point of time with which other service.
Like all other DevOps infrastructure, your monitoring infrastructure cannot be "fire and forget" - it needs to be developed like any other software.
In the context of monitoring this means continually evaluating whether you are giving
So the solution here lies outside the choice of tools, and really is decided upon the practices surrounding those tools.