Petes Linkedin Blog

In this guide we will learn how to spin up GitLab in the AWS Marketplace: Pre requisites for this lab are having an account in AWS and an accessible and working VPC. We will learn the following steps: Stand up a self-managed instance of GitLab. Install Runner and Docker Engine. Step-by-step Instructions Step 1 - Stand up GitLab instance in AWS Open GitLab Ultimate in AWS Marketplace. Click on Continue to Subscribe Sign in with your IAM user. Click on Continue to Configuration . Leave the default value for Delivery Method , select the latest version in Software Version , select your Region , click Continue to Launch . In Launch this software page, scroll down. Under Security Group Settings click Create New Based On Seller Settings . Name your security group, add a description, and save it. Select Key Pair . If you don't have key pair, create one. Leave other fields in this page with default values. Click Launch . You will get Congratulat...

GitLab uses a GPG key to sign all Omnibus packages created within the CI pipelines to insure that the packages have not been tampered with. This key is seperate from the repository metadata signing key used by package managers and the GPG signing key for the GitLab Runner. The Omnibus package signing key is set to expire on July 1, 2021 and will be extended to expire on July 1, 2022 instead. Why are we extending the deadline? The Omnibus package signing key's expiration is extended each year to comply with GitLab security policies and to limit the exposure should the key become compromised. The key's expiration is extended instead of rotating to a new key to be less disruptive for users that do verify package integrity checks prior to installing the package. What do I need to do? The only action that needs to be taken is to update your copy of the package signing key if you validate the signatures on the Omnibus packages that GitLab distributes. The package signing key is...

Today we are releasing version 14.0.1 for GitLab Community Edition and Enterprise Edition. This version resolves a number of regressions and bugs in this month's 14.0 release and prior versions. GitLab Community Edition and Enterprise Edition Available in GitLab Free, Premium, and Ultimate: Update Geo UI screenshots in docs page Update admin docs with new admin area access info Add Helm-2to3.gitlab-ci.yml to Auto DevOps Update docs for new Members page location on GitLab navigation DevOps Adoption - ensure displayNamespaceId is included Remove add button from Devops Adoption Geo: Add Terraform Module to datatypes doc Create 14.0 What's New entry Toggle codequality diff annotations flag Bump kas to v14.0.1 Exempt unicorn 'svlogd_prefix' from deprecation check 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 packag...

In the previous post, titled 3 ways to approach GitOps , we discussed the many benefits and options that GitLab supports for fulfilling the GitOps requirements of customers, whose IT environments are composed of heterogeneous technologies and infrastructures. This post is a 3-part series, in which we delve deeper into these options. In this first part, we cover the pull-based or agent-based approach. About a pull-based or agent-based approach In this approach, an agent is installed in your infrastructure components to pull changes whenever there is a drift from the desired configuration, which resides in GitLab. Although the infrastructure components could be anything from a physical server or router to a VM or a database, we will focus on a Kubernetes cluster in this section. In the following example, the reconciliation loop is made up of two components: an agent running on the Kubernetes cluster and a server-side service running on the GitLab instance. One of the benefits of this...

When we think of everything released in the year since GitLab 13.0, we could not be more proud of our community and our team. This month, we celebrate our release of GitLab 14.0 by first taking a step back. Together, we’ve made so much progress over the last year that we want to talk about everything it took to get to GitLab 14 . We use semantic versioning so a point release, like 14.0, represents everything new in this month. GitLab 14 is the culmination of the past year. Even more than that, GitLab 14 represents the future of GitLab, and the future of DevOps. With GitLab 14, teams of all sizes are moving from maintaining DIY DevOps toolchains to adopting modern DevOps. GitLab 14 is a complete DevOps platform with security embedded in its DNA, visibility and insights enabled by its single data store, and a seamless experience and extensible system, so end users and enterprises alike reap the benefits of speed and efficiency. We’re so excited that we’ve written a post where you can...