How to lighten the load on your container registry using Quay.io
Using Buildah, Skopeo, and Quay.io to create a container registry.
Tom Sweeney
Fri, 12/11/2020 at 5:30pm
Image
Image by Dariusz Sankowski from Pixabay
In this post, I show you how to use Quay.io to host container images, and how to avoid over-taxing your container registry by limiting unnecessary requests for images. I use Buildah, Skopeo, and Quay.io, but the tips on limiting image pulls will work with any container registry you might use.
Topics:
Containers
Linux Read More at Enable Sysadmin
The goal of continuous delivery (CD) is to produce high-quality software rapidly. While the emergence of microservices and cloud-native technology has brought huge benefits in scalability, it has added a layer of complexity to this approach. Security is another big challenge. In this discussion with Tracy Miranda, Executive Director of the Continuous Delivery Foundation, we talked about some of the pain points the organizations face when bolstering their CD practices and how the Foundation is helping to address them.
Swapnil Bhartiya: How would you define continuous delivery? Also, what about the CI part of it because when we talk about it, we always say CI/CD?
Tracy Miranda: We define continuous delivery as a software engineering approach in which teams work in short cycles and they ensure that the code is always released at any point in time. Now, traditionally, people tend to speak a lot about continuous integration and continuous delivery (CI/CD). Continuous integration is when developers regularly commit at least once a day to a mainline and keep that main line up to date. But I see continuous delivery as really this umbrella of all the practices you need to keep that software ready to be released at any time. That includes continuous integration, security features, testing and so on. It’s a general set of practices.
Swapnil Bhartiya: CI/CD is a solved problem and there are many open-source projects around it. What role is the Foundation playing in this space?
Tracy Miranda: We know a lot about continuous delivery today and we appreciate that it is really important because it makes such a difference to every business today — not just software companies, but also banks and the healthcare industry. However, the adoption of continuous delivery practices is super low. Many people think they’re doing it, but maybe they’re doing some continuous integration and they haven’t quite figured out how to get through automation.
To top it off, what makes things even more complicated is we’ve seen the rise of microservices and cloud-native technology. While these give us huge benefits in terms of scalability and easy to work on separate parts of the application, they have also increased challenges, like a proliferation of environments and teams having to contend with all these different parts that make up an application.
The Continuous Delivery Foundation is there to help support teams and organizations in the adoption of these practices both from the sense of taking advantage of open source projects in the space and democratizing the best practices. We have a very recent working group that’s spun up to help anyone in this space get better at delivering software.
Swapnil Bhartiya: Security is becoming a serious concern and no longer an after-thought. In most cases, we see that companies were compromised not because of some zero-day, but because they didn’t apply the patch to a known vulnerability. When you have billions of deployments of your applications, it becomes challenging. Talk about the role CD plays in improving security.
Tracy Miranda: Security is a top concern. I think there are lots of different elements to this. On one hand, we talk a lot about shift-left of security. We need to make sure the security professionals and the folks focused on security are tightly involved with the rest of the team. So, there are no silos. People don’t regard security as someone else’s problem. Security starts with the developers.
As an industry, I think it’s really important that we work together to solve industry-level problems such as applying patches that are already available. It’s more or less an outreach problem. We need to be better at telling people to keep their systems updated. We need to cut through the noise of all the different messaging they’re hearing. I think that’s another example where something like the Continuous Delivery Foundation can make a difference in addressing these broad industry problems.
Swapnil Bhartiya: You also mentioned microservices as a challenge for companies. What is being done around solving the problem of continuous delivery for microservices?
Tracy Miranda: That’s a great question. We definitely have the big split of folks who are used to delivering a monolith and they have their existing setup, all geared towards supporting that. Then, there is an increasing number of folks who are trying to take advantage of microservices and all its implications. One of the hot topics that’s emerged for us is configuration management. How we think about this is earlier, the scope of your application was very well defined. With microservices, the definition of an application changes — it’s a set of microservices. How do we talk about which version of each microservice goes into a specific app? If we are continuously pushing code and integrating that, how are those different versions changing relative to each other? How are we testing that all together? So, we’ve definitely think configuration management is a really hot topic and people are looking at tooling in the space. I think we have a couple of interesting projects that might be coming in the pipeline to CDF that will specifically help to drive visibility into this space and give people better tooling to manage all the dependencies around microservices.
Swapnil Bhartiya: There are so many projects and open-source tools for CD, which may also lead to a problem of interoperability. How big is it a concern for the Foundation and what are you doing to increase interoperability within these tools?
Tracy Miranda: Interoperability is one of those problems where if you’re just working in your own organization, sometimes, it’s not really a problem until it’s time to adopt a new tool or add something into your workflow. If we step back and look at the industry as a whole and take a look across the whole landscape, at the moment, it’s hugely fragmented. There’s a lot of tools doing similar things. It’s very difficult for people to move from different CI tools or different pipeline orchestration tools without having to go through a lot of pain to figure out how to do that. Providers have to implement plugins for different systems. It’s a waste of time and it slows down innovation when we could be moving up the stack.
I think where we are today, there’s a greater appreciation from end users who are saying “We want to simplify this. We want to find better ways for tools to interoperate.” At CDF, one of the very first special interest groups we had was an interoperability working group. This is a set of like-minded folks who got together and said, “As an industry, we should be better and we can be better. We need to figure that out.” It’s a really good group of folks that build the projects like Jenkins X, Tekton, and Spinnaker. We’ve also got a lot of end-user members represented like Ericsson and eBay to make sure that as the problems are being solved, they apply to real-world use cases.
It’s an open group and people are welcome to join these conversations. At the moment, there is a discussion on standardizing interfaces or metadata. Why can’t we have a standardized way to express all the metadata around a release or all the metadata around a set of testing results? I am really excited about what this group is doing and look forward to if they can really achieve this very difficult goal and bring some consolidation around the tooling.
Swapnil Bhartiya: One last question before we wrap this up: how is COVID-19 affecting continuous delivery?
Tracy Miranda: It has definitely increased. We have seen some surveys that show that the adoption of continuous delivery is increasing. The pandemic has emphasized the need to be more resilient and to adapt quickly. Most organizations are going to evolve to be very distributed. Continuous delivery practices enable all those things. The companies who are already doing these practices have a significant advantage in times like these. I think one of the benefits we have as a Foundation is that open source has always been about collaboration at scale and in a distributed way. So, we’re hoping we can take all those lessons and marry open-source practices to continuous delivery practices and make it easier for everybody to adopt them. It shouldn’t be something elite that only a few companies could do. It should be something that’s possible and achievable for every company and every organization out there.
Taking the labor out of labor-intensive tasks is what Ansible is all about. Learn the basics here.
Pratheek Prabhakaran
Tue, 12/8/2020 at 6:54pm
Image
Photo by Aphiwat chuangchoem from Pexels
The life of a sysadmin involves installation, configuration, performing regular system upgrade and maintenance activities, provisioning, system monitoring, vulnerability mitigation, troubleshooting issues, and much more. Many sysadmin actions consist of step-by-step tasks performed methodically. So how can we make the life of a sysadmin easier?
[ Readers also enjoyed: An introduction to Ansible Tower ]
Topics:
Linux
Ansible
Automation Read More at Enable Sysadmin
Linux authentication is primarily handled with passwords and public keys. Find out how the passwd command fits into the user management process. Read More at Enable Sysadmin
Free and Open Source Software (FOSS) has become a critical part of the modern economy. It has been estimated that FOSS constitutes 80-90% of any given piece of modern software, and software is an increasingly vital resource in nearly all industries. This heavy reliance on FOSS is common in both the public and private sectors, in both tech and non-tech organizations. Therefore, ensuring the health and security of FOSS is critical to the future of nearly all industries in the modern economy.
To better understand the state of security and sustainability in the FOSS ecosystem, and how organizations and companies can support it, the Linux Foundation‘s Core Infrastructure Initiative (CII) and the Laboratory for Innovation Science at Harvard (LISH) collaborated to conduct a widespread survey of FOSS contributors as part of larger efforts to take a pre-emptive approach to strengthen cybersecurity by improving open-source software security.
These efforts — recently incorporated into the Open Source Security Foundation (OpenSSF) working group on securing critical projects — aim to support, protect, and fortify open software, especially software critical to the global information infrastructure.
This survey’s primary goal is to identify how best to improve FOSS’s security and sustainability — especially those projects that are widely relied upon by the modern economy. Specifically, the survey seeks to help answer the question,
“How can we better incentivize adequate maintenance and security of the most used FOSS projects?”
Importantly, in conducting this survey, the research team sought to take a holistic view of security. The methodology for recruiting survey participants emphasized contributors to FOSS projects that have been identified as widely used via previous research that culminated in the release of “CII Census II Preliminary Report – Vulnerabilities in the Core.”
This new report summarizes the results of a survey of free/open source software (FOSS) developers in 2020. The goal was to identify key issues in improving FOSS’s security and sustainability since the world now depends on it as a critical infrastructure that underlies the modern economy.
To capture a cross-section of the FOSS community, the research team distributed the survey to contributors to the most widely used open source projects and invited the wider FOSS contributor community through an open invitation. It captured more technical aspects of security and also considered the more human side.
The survey included questions about contributor motivations and level of involvement, corporate involvement in FOSS, the role of economic considerations in contribution behavior, and sought to answer the following:
Demographics: What are the demographics of FOSS contributors? In particular, what are their gender, employment, and geographic location?
Motivations: What are their reasons for starting, continuing, or stopping contributions to FOSS? How can projects keep contributors engaged, and do contributors feel that their employers or others value their work?
Pay: How many FOSS contributors are paid for their work on FOSS? If paid, by whom (e.g., by employers and/or corporate sponsorship)? If they are not, does the lack of payment lead to significantly poorer security or sustainability?
Time Spent: How much time do contributors spend contributing to FOSS, and how would they like to spend it? Is there an interest in increasing time spent on security issues?
Aid: What kinds of actions from external actors would help improve security (e.g., code contributions and/or money)?
Current activity: What kinds of security-related activities are already taking place in the FOSS projects represented by the respondents?
Education/training: How much education/training have FOSS contributors had in secure software development and operations? From which sources did they receive it?
The goals in running this survey were to understand the state of security and sustainability in FOSS and identify opportunities to improve them, and ensure FOSS’s viability in the future. In particular, this survey focused on the “human side” of FOSS, more than the technical side, although the two are certainly inter-related, and these findings relate to both.
The results identified reasons for optimism about the future of FOSS (individuals are continuing to contribute to FOSS, companies are becoming friendlier to FOSS to the point of paying some employees to contribute, etc.), but also areas of concern (in particular, the lack of security-related efforts, and potential difficulties in motivating such efforts).
In the end, free and open source software is, and always has been, a community-driven effort that has led to the development of some of the most critical building blocks of the modern economy. This survey highlights the importance of the security of this important dynamic asset. Likewise, it will take a community-driven effort, including individuals, companies, and institutions, to ensure FOSS is secure and sustainable for future generations.
Authors:
Frank Nagle, Harvard Business School
David A. Wheeler, The Linux Foundation
Hila Lifshitz-Assaf, New York University
Haylee Ham, Laboratory for Innovation Science at Harvard
Jennifer L. Hoffman, Laboratory for Innovation Science at Harvard
A high-level walkthrough of CI/CD Automation troubleshooting techniques with multiple, significantly impeding factors blocking progress. Read More at Enable Sysadmin
Sure, you can manually encrypt a filesystem. But, you can also automate it with Ansible.
Peter Gervase
Mon, 12/7/2020 at 4:52pm
Image
Photo by PhotoMIX Company from Pexels
There are a few different reasons that you might want to encrypt a filesystem, such as protecting sensitive information while it’s at rest, not having to worry about encrypting individual files on the filesystem, or other reasons. To manually encrypt a filesystem in Red Hat Enterprise Linux (RHEL), you can use the cryptsetup command. This article will walk you through how to use Ansible to do this for you for a RHEL 8 server.
Topics:
Linux
Linux Administration
Security Read More at Enable Sysadmin
SSH continues to be a go-to command line tool for system administrators. These six guides reveal key ways that SSH plays a crucial role in getting the job done. Read More at Enable Sysadmin
What are you going to do to continue to advance your career or enhance the practice of this shared sysadmin craft? These six guides can help improve your career. Read More at Enable Sysadmin