chore: various grammar fixes

Signed-off-by: Jaime Silvela <[email protected]>

Author: jsilvela

content/blog/building-images-bake/index.md

@@ -20,23 +20,26 @@ summary: Creating a container image for CloudNativePG Operator v2.0
 ---
 
 ## Summary
-In an almost [two years old blog post](https://cloudnative-pg.io/blog/creating-container-images/), we explained how
-to build a custom container image for CloudNativePG. After two years, many things have changed in the containers world,
-one of those things was the introduction of [Bake](https://www.docker.com/blog/bake/) in Docker, which allows you to build
-images using a simple configuration file, and it is now our recommended way to build images for CloudNativePG.
+In an almost [two years old blog post]({{% ref "/blog/creating-container-images/" %}}), we explained how
+to build a custom container image for CloudNativePG. After two years, many things have changed in the world of containers.
+One of those things was the introduction of [Bake](https://www.docker.com/blog/bake/) in Docker, which allows you to build
+images using a simple configuration file. Bake is now our recommended way to build images for CloudNativePG.
 
 We will follow a simple cooking recipe to create a custom container image or a set of container images, since Bake
-allows you to build multiple images at once in a pretty simple way.
+allows you to build multiple images at once in a simple way.
 
 ## Ingredients
-- A bake file, we will use the one provided in the [CloudNativePG repository](https://github.com/cloudnative-pg/postgres-containers/blob/main/docker-bake.hcl)
 
-Cooking time: 5 minutes
+- A bake file. We will use the one provided in the [CloudNativePG repository](https://github.com/cloudnative-pg/postgres-containers/blob/main/docker-bake.hcl)
+
+Cooking time: 5 minutes.
 
 ## Instructions
 
 ### Step 1: Prepare local bake file
+
 In a local file with name `bake.hcl`, we add the following content, which is a simple bake file that will build a custom image
+
 ```hcl
 extensions = [
   "pgvector",
@@ -70,69 +73,75 @@ EOT
     EXTENSIONS = "${getExtensionsString(pgVersion, extensions)}",
   }
 }
-
 ```
-There's a couple of things that we can remark here:
-* The `extensions` variable is a list of extensions that we want to include in the image, in this case we are using `pg_vector`,
+
+There are a few things that we should remark here:
+
+- The `extensions` variable is a list of extensions that we want to include in the image. In our recipe we are using `pg_vector`,
   but you can add any other extension that you want to include in the image.
-* The `dockerfile-inline` variable contains our Dockerfile definition, which cannot be used remotely, will explain more about this later.
-* The `target` and the `tgt` have the same name, you can use what ever you want here as a name
-* The `pgVersion` is a variable list that contains basically, the MAJOR.MINOR version of PostgreSQL
-* The `name` is the name that we will use later to refer to one element of the matrix that we created
-* The `args` is all the arguments passed to the Dockerfile, will talk more about this later.
-* The function `getExtensionsString()` is one that is inherited from a bake file that we reference in the [Ingredients](#ingredients) section
+- The `dockerfile-inline` variable contains our Dockerfile definition, which cannot be used remotely. We will explain more about this later.
+- The `target` and the `tgt` have the same name, you can use what ever you want here as a name
+- The `pgVersion` is a variable list that contains basically, the MAJOR.MINOR version of PostgreSQL
+- The `name` is the name that we will use later to refer to one element of the matrix that we created
+- The `args` lists all the arguments passed to the Dockerfile. We will talk more about this later.
+- The function `getExtensionsString()` is inherited from the bake file that we reference in the [Ingredients](#ingredients) section
 
 ### Step 2: Build the image
 
 We can now build the image using the following command:
+
 ```bash
 docker buildx bake -f docker-bake.hcl -f cwd://bake.hcl "https://github.com/cloudnative-pg/postgres-containers.git" myimage
 ```
-This will, by default, build the image for the bake matrix we previously created and will try to push the image to the registry
-`localhost:5000`, which is the default registry defined for testing environments in the parent bake file, so let's explain the full command first.
+This will, by default, build the image for the bake matrix we previously created, and will try to push the image to the registry at
+`localhost:5000`, which is the default registry defined for testing environments in the parent bake file. Let's explain the full command first.
 
-As is defined in the [Bake documentation about remote definition](https://docs.docker.com/build/bake/remote-definition/)
-you can use a remote bake definition with all the functions and default targets and attach another local one that you can use to override
-all the default values, in this case the `-f cwd://bake.hcl` is the local file that we created in the previous step, and
-the `-f docker-bake.hcl` is the remote file that we're using to build the image, this is in the git repo.
+As is defined in the [Bake documentation about remote definitions](https://docs.docker.com/build/bake/remote-definition/)
+you can use a remote bake definition with all the functions and default targets, and attach another local one that you can use to override
+all the default values.
+In the command above, `-f cwd://bake.hcl` is the local file that we created in the previous step, and
+`-f docker-bake.hcl` is the remote file that we're using to build the image, which is in the git repo.
+
+You can explore more about all the content generated and used inside the bake file by appending the `--print` flag, as in the following command:
 
-You can explore more about all the content generated and used inside the bake file with the following command:
 ```bash
 docker buildx bake -f docker-bake.hcl -f cwd://bake.hcl "https://github.com/cloudnative-pg/postgres-containers.git" myimage --print
 ```
 
 ### Step 3: Push the image to a registry
 
 Now you just need to push the image to a registry, you can do this by using the following command:
+
 ```bash
 registry=your/registry:5000 docker buildx bake -f docker-bake.hcl -f cwd://bake.hcl "https://github.com/cloudnative-pg/postgres-containers.git" myimage --push
 ```
-The previous command will push the images in the following format `your/registry:5000/postgresql-testing:17-standard-bookworm`,
-using the `--print` you can explore the full list of tags created that are in the parent bake file.
+
+The previous command will push the images in the following format: `your/registry:5000/postgresql-testing:17-standard-bookworm`.
+Using the `--print` flag you can explore the full list of tags created that are in the parent bake file.
 
 ### Step 4: Serve the image
 
-You can now let your clusters to use the image that it's built and based on the CloudNativePG operand images provided
+You can now let your clusters use the image that we've built based on the CloudNativePG operand images provided
 by the CloudNativePG project.
 
 ## Deep dive into the Bake and Dockerfile
 
-The simplicity of Bake to bring more stuff is amazing and allows you to create a custom image in a very simple way.
-But, how is this magic happens? Let's take a look at the Bake and the Docker file.
+The simplicity of Bake to do even more stuff is amazing, and allows you to create custom images in a very simple way.
+But, how does this magic happen? Let's take a look at the Bake and the Docker file.
 
 ### Bake file
 
 This is the base of our magic, but that magic starts in our postgres-containers repository, where we have a `docker-bake.hcl` file
-that it's being used to build the images provided by the CloudNativePG project, and it's the base for our custom Bake file.
+that is being used to build the images provided by the CloudNativePG project, and it's the base for our custom Bake file.
 
-
-The `docker-bake.hcl` file contains a lot of functions that are used to build the images, and one of them is the `getExtensionsString()`,
-this one, using the list of extensions we provided, will return a string of the extensions with the correct package name
-for a Debian-based distribution, in our case, Debian Bookworm, so the `pg_vector` extension will be translated into
-`postgresql-16-pgvector` which will be the name of the package of pgvector extensions for PostgreSQL 16 in the Debian
+The `docker-bake.hcl` file contains a lot of functions that are used to build the images, and one of them is the `getExtensionsString()`.
+This function, using the list of extensions we provided, will return a string of the extensions with the correct package name
+for a Debian-based distribution, in our case, Debian Bookworm.
+So the `pg_vector` extension will be translated into
+`postgresql-16-pgvector` which is the name of the package for pgvector extensions for PostgreSQL 16 in the Debian
 Bookworm distribution.
 
-Even the variable that are passed in the `args` variable to the Dockerfile are processed by the Bake file, in this case,
+Even the variables that are passed in the `args` variable to the Dockerfile are processed by the Bake file, in this case,
 the variables we add, are being added and the ones we overwrite are being overwritten, so we can use the same variables
 and content used in the parent Bake file.
 
@@ -145,10 +154,12 @@ on the CloudNativePG images, and we can add the extensions we want to use in our
 ## There's more!
 
 You may want to avoid building arm64 image by adding the following:
+
 ```hcl
 platforms = ["linux/amd64"]
 ```
-This will overwrite the platforms variable and so, will build only for one platform
 
-Also, if you want to build everything into your own repository and manage the same tags, it's possible, in the future
-we may write another post explaining this
+This will overwrite the platforms variable and so, will build only for one platform.
+
+Also, if you want to build everything into your own repository and manage the same tags, it's possible. In the future
+we may write another post explaining this.