Petes Linkedin Blog

In a recent blog post discussing the progress of integrating novel machine learning (ML) algorithms into GitLab we introduced our new ModelOps stage . This stage is focused on enabling and empowering data science workloads on GitLab. GitLab ModelOps aims to bring data science into GitLab within existing features to make them smarter and more intelligent and empowering GitLab customers to build and integrate data science workloads within GitLab . An interesting question we hear a lot is how will this be useful for DevOps professionals? So we wanted to dive into who exactly we’re building ModelOps features for and why. To begin, here is an overview of how we’ve chosen to structure our new ModelOps stage.  ModelOps: Enabling and empowering data science workloads ModelOps is about taking all the best practices we’ve learned building a DevOps platform and applying them to the unique challenges of AI and ML workloads. Our ModelOps stage is divided into three primary groups: DataOps,...

In this post we look back on a series of projects from the Scalability team that improved GitLab server-side efficiency for serving Git fetch traffic. In the benchmark described below we saw a 9x reduction in GitLab server CPU utilization. Most of the performance comes from the Gitaly pack-objects cache, which has proven very effective at reducing the Gitaly server load caused by highly concurrent CI pipelines. These changes are not user-visible but they benefit the stability and availability of GitLab.com. If you manage a GitLab instance yourself you may want to enable the pack-objects cache on your instance too. We will discuss how we achieved these improvements in part 2, coming soon (and will be linked here). Background Within the GitLab application, Gitaly is the component that acts as a remote procedure call (RPC) server for Git repositories. On GitLab.com, repositories are stored on persistent disks attached to dedicated Gitaly servers, and the rest of the application acces...

Container Host Security in GitLab provides intrusion detection and prevention capabilities that can monitor and (optionally) block activity inside the containers themselves. In this blog post, we will go over the basic concepts of Container Host Security. We will then use GitLab-Managed Apps to deploy Falco into our Kubernetes Cluster using the GitLab CI/CD pipeline. After that, we will set up Falco rules, examining when those rules have been broken, and create alerts. Falco Logs and Alerts will provide us an insight to potential malious behavior occuring in our infrastructure. I created the Initech Infrastrucute project to showcase all the different integrations with Kubernetes. Feel free to clone it for this guide. What is Container Host Security? Container Host Security refers to the ability to detect, report, and respond to attacks on containerized infrastructure and workloads. For Container Host Security, GitLab relies on Falco. Falco is a cloud native, easy-to-use security ...

In a remote, asynchronous company, is there ever a time when teams need to collaborate synchronously? We recently asked ourselves that question on the Monitor team. It had been three years since we started thinking about how to build out Incident Management as a team, and a lot had happened in that time. We’d built out a range of new features and created the broad outlines for a complete incident management workflow with GitLab. We’d achieved a lot. We had also been through a number of changes as a team, and we had several possible paths ahead of us. It felt like an appropriate moment to step back and take stock of where we’ve been, what we’ve done, and where we still need to go. However, given our team's geographical distribution, we realized we needed to think creatively about how best to create space for reflection as a team. Opting for a Lightning Decision Jam Outside of regularly scheduled team meetings, our team adheres to the standard GitLab practice of prioritizing asyn...

Over the last six months, we’ve asked teams and individual contributors to assess their DevOps platform practices by answering a 20-question quiz. To date, more than 600 people have shared their experiences, providing a clear, and somewhat surprising, snapshot of DevOps as it’s done today . There are obvious technical wins, of course, but there are also glimpses of how DevOps and modern software development are driving business change. Here are some of the key takeaways: DevOps is a stand up (and out) choice Almost 35% of respondents say they’ve been doing DevOps for between one and three years, while 22% report they’ve been at DevOps less than a year. And 16% are in that DevOps sweet spot of between three and five years, while 15% are seasoned DevOps pros with more than five years of experience. DevOps, of course, enables faster and safer software development and it’s clearly taking teams and entire organizations along for the ride, with much greater levels of collaboration/planni...

Today we are releasing version 14.6.3 for GitLab Community Edition and Enterprise Edition. This version resolves a number of regressions and bugs in last month's 14.6 release and prior versions. GitLab Community Edition and Enterprise Edition Geo: adapt verification timed out query to use state table Fix migration for cases with empty strings Fix the order of subsequent jobs when requeuing a job Geo: Resolve "undefined method each_batch" Fix destruction of projects with pipelines Revert chef-acme cookbook update Update golang to 1.16.12 Pass knapsack generate report var to gitlab-qa Important notes on upgrading This version does not include any new migrations, and for multi-node deployments, should not require any downtime . Please be aware that by default the Omnibus packages will stop, run migrations, and start again, no matter how “big” or “small” the upgrade is. This behavior can be changed by adding a /etc/gitlab/skip-auto-reconfigure file, which is...

Today’s DevOps platform-centric world is moving steadily towards an "Everything-as-Code" mentality. Add in cloud native, and it's clearly even more important to standardize how you define your DevOps processes. Why ‘as-Code’? Thanks to faster iteration, cloud native computing, and microservices-based architectures, as-Code technologies have become the de-facto standard for a lot of different parts of the software development lifecycle. The need to release faster requires a single spot for teams to collaborate on any kind of change – code, infrastructure, configuration, networking, or testing. And to implement that change quickly we need to be able to see and review it before it goes into production. As-Code solutions are at the core of cloud native technologies such as Kubernetes, where you utilize YAML or JSON formats to configure and manage. Here are the key advantages of 'as-Code': auditability scalability efficiency collaboration These benefits come...