The CFEngine lab has been brewing on 3.6.4 over Christmas and is finally ready to release it to the world! With 3.6.4 being a patch release, it has a focus on stability and reliability of both the server and agent side. This is also the first release where user input has been incorporated in form of casting a vote for what to be improved - so make your voice heard!
Enterprise hub self-protection A major stability enhancement for report collection in CFEngine Enterprise hubs has been added to 3.6.4. The Enterprise hub collects reports from clients every 5 minutes by default, but in cases where it can not collect a round of reports from a client it will try to get what is missed the next time from that client; after another 5 minutes. This could happen for several reasons, for example that the client is temporarily offline. The amount of data that needs to be collected once the report collection succeeds again is proportional to the amount of time has passed since the last success. However, if the hub as been unsuccessful at collecting reports from a large amount of clients over a longer period of time, this can cause a high load on the hub once it succeeds again; potentially making the hub unstable and unresponsive until the collection is done. CFEngine 3.6.4 addresses this potential stability problem by introducing a maximum threshold on how long history the hub will try to collect from clients that have been offline; through the body hub control attribute client_history_timeout. By default the hub will discard the missed history (known as issuing a “rebase” collection query) from clients if more than 6 hours have passed since last successful collection in order to protect itself. If a client comes back after 6 hours, the load on the hub for discarding these last 6 hours versus collecting them are about the same – thus the 6 hour default. However, you can adjust this threshold if you expect your clients to be offline for longer amounts of time during normal operations. Note that in either case, history that already exists about the client in the hub’s database is not discarded.
CFEngine 3.6.3 is released! The new version brings broader platform support, UI performance and usability enhancements as well as bugfixes. It has again been about 8 weeks since the last release, and we are planning to further shorten the release intervals going forward to bring you enhancements faster. What you will also notice is that the focus is on stability and performance for 3.6.x releases, in order to make upgrades as safe as possible. Features and larger changes will be provided in the 3.7 branch.
In this blog post I would like to show how one of the best configuration management solution integrates with an equally well known ticketing system - Jira When a specific policy becomes out of compliance, there is a common need to integrate this with a ticketing system. For example, you have an important web application configured and ensured to be running using CFEngine. If any aspect of that fails, you want to be notified immediately. But since you already get enough email, and you already use a ticketing system for all other tasks, you want to open an issue in the JIRA issue tracking system on such an event. CFEngine 3.6.2 introduces Custom actions as a notification method for alerts, which virtually enables any notification method for any event happening in your infrastructure. In our new How To, we show how to integrate CFEngine with JIRA using Custom actions. Let CFEngine open a ticket for you whenever something important happens with your infrastructure, and spend your time planning instead of monitoring!
CFEngine 3.6.2 is now available - in both Community and Enterprise editions! There are major new features in the Enterprise hub; High Availability and Custom actions. In addition, we have resolved numerous issues to provide you with a very stable release. It has been about 8 weeks since the 3.6.1 release, and we plan to continue on a 6-8 week schedule for maintenance releases going forward.
High availability for the hub A common requirement for most enterprises is that key processes and mission critical applications are highly available - in essence to ensure there is no single point of failure. Although CFEngine is a distributed system, with decisions made by autonomous agents running on each node, the hub can be viewed as a single point of failure. Essentially, the hub has two responsibilities:
This blog is the result of joint technology collaboration between Arista Networks and CFEngine Inc.
Introduction It is an accepted fact that the disciplines of system administration and network administration are traditionally very disjoint: different teams, different knowledge, different tools and different goals. For example, does the networking team know which nodes and applications are affected by a change on a specific switch? Is the network topology actually the way it says it is in the design diagrams? Unfortunately, network design diagrams and server CMDBs quickly grow out of sync with reality in today’s fast-changing world. This makes questions like the above virtually impossible to answer, thus leaving luck to play an important role in what changes lead to downtime, loss of revenue and late-hour emergency fixes. However, times are changing and one of the promises of the DevOps movement is enabling better collaboration across these teams. The first step towards collaboration is to enable holistic visibility of the current configuration of the environment, which includes applications, servers and the network connecting them. A popular use case for CFEngine today is to update server CMDBs with the current information. CFEngine can do this as it is running on all the nodes and provides a server-side API for the inventory - as it was seen 5 minutes ago. The missing piece is to also extend this and enable this in the network layer. In this blog series, a joint-effort between Arista and CFEngine focused on network automation, we will look at how to discover and report complete inventory information with CFEngine running on Arista switches (this part), as well as how to easily extend the information using the new Arista APIs (part two).
Inventory management in 3.6, part 1 - Showing variables and classes CFEngine 3.6 introduces a set of features for inventory management, and we’ll have a closer look at one of them today. This feature is part of both the Community and Enterprise editions. It essentially outputs the inventory in terms of classes and variables at a local node. Have a quick look at cf-promises -h of 3.6:
cf-promises -h Usage: cf-promises [OPTION]… [FILE] Options: –eval-functions, - value - Evaluate functions during syntax checking (may catch more run-time errors). Possible values: ‘yes’, ’no’. Default is ‘yes’ –show-classes, - - Show discovered classes, including those defined in common bundles in policy –show-vars , - - Show discovered variables, including those defined anywhere in policy –help , -h - Print the help message … You might see the two new options –show-classes and –show-vars. Let’s test them out.
eystein.maloy.stenberg@cfengine.com Product Management, CFEngine Introduction The beauty and power of Docker comes from its ability to containerize any application into a portable self-sufficient entity, one that can run anywhere. This enables developers to deliver an application with all dependencies in a layered image structure. As if that was not enough, the images can be shared in an image repository (known as the Docker index) and deployed to and run on any Docker host. CFEngine, a pioneer in IT automation, enables organizations to become more agile by radically simplifying, automating and transforming the way they build, deliver and consume IT infrastructure and applications. With CFEngine, some of the largest IT organizations provision resources and deploy new applications orders of magnitude faster, while ensuring continuous availability, security and compliance in large-scale, very dynamic and highly complex environments. After applications are deployed, maintenance tasks such as process management and signaling, log management, and managing run-time configuration consistency and compliance become important. CFEngine is designed to be very lightweight, distributed and fault-tolerant. These attributes make it very well suited for managing containerized Docker applications. CFEngine is an extremely versatile technology and a good complement to Docker, which is very strong at getting code containerized, shipped and deployed. Advancing Process Management in Docker Docker monitors one process in each running container and the container lives or dies with that process. By introducing CFEngine inside Docker containers, we can alleviate a few of the issues that may arise:
The CFEngine team is excited to present - CFEngine Week in New York City, October 14-18!
During that week we will be out in force in the Big Apple. Come meet us in one of the many events we are organizing or sponsoring:
Velocity Conference, Oct 14-16: Most companies with outward-facing dynamic websites face the same challenges: pages must load quickly, infrastructure must scale efficiently, and sites and services must be reliable, without burning out the team or breaking the budget. Velocity is the best place on the planet for web ops and performance professionals to learn from peers, exchange ideas with experts, and share best practices and lessons learned.
Every year, on the last Friday of July, we pause for a moment and think about the impact of system administrators on our world. It is hard to imagine how different our life would be if it was not for the sysadmin. The goal of the Annual SysAdmin Appreciation Day is to make us all think about that and find ways to express our appreciation for them. At CFEngine we know many of them. In the past weeks we have interviewed hundreds of them and we want to share some fun facts we have discovered which show why they deserve our appreciation.
Bruce Carleton is the organizer of the San Francisco CFEngine User Group. He has a deep understanding of system administration for distributed systems and how to make it easy (and fun!) to use CFEngine for that. He sent a message to the user group email list, that we want to share with you:
Re: [SF-Cfengine-Users-Group] Automation Adoption Challenges and Analogies
During the last SF CFEngine users group, we had a good discussion about promoting adoption of CFEngine in our various environments. It can be a challenging thing to do, and I think it’s worth sharing some of my thoughts on the matter. This is an edited version of an email I sent out on the help-cfengine mailing list, so I apologize in advance for the resend to those who have dual subscriptions.
