diff options
Diffstat (limited to 'doc/user')
17 files changed, 368 insertions, 407 deletions
diff --git a/doc/user/clusters/applications.md b/doc/user/clusters/applications.md index f2dd4319f88..105843fd678 100644 --- a/doc/user/clusters/applications.md +++ b/doc/user/clusters/applications.md @@ -107,10 +107,20 @@ To resolve this: project that is used to run your jobs and send the results back to GitLab. It is used in conjunction with [GitLab CI/CD](../../ci/README.md), the open-source continuous integration -service included with GitLab that coordinates the jobs. When installing -the GitLab Runner via the applications, it will run in **privileged -mode** by default. Make sure you read the [security -implications](../project/clusters/index.md#security-implications) before doing so. +service included with GitLab that coordinates the jobs. + +If the project is on GitLab.com, shared Runners are available +(the first 2000 minutes are free, you can +[buy more later](../../subscriptions/index.md#extra-shared-runners-pipeline-minutes)) +and you do not have to deploy one if they are enough for your needs. If a +project-specific Runner is desired, or there are no shared Runners, it is easy +to deploy one. + +Note that the deployed Runner will be set as **privileged**, which means it will essentially +have root access to the underlying machine. This is required to build Docker images, +so it is the default. Make sure you read the +[security implications](../project/clusters/index.md#security-implications) +before deploying one. NOTE: **Note:** The [`runner/gitlab-runner`](https://gitlab.com/gitlab-org/charts/gitlab-runner) @@ -129,11 +139,112 @@ web proxy for your applications and is useful if you want to use [Auto DevOps](../../topics/autodevops/index.md) or deploy your own web apps. NOTE: **Note:** +With the following procedure, a load balancer must be installed in your cluster +to obtain the endpoint. You can use either +Ingress, or Knative's own load balancer ([Istio](https://istio.io)) if using Knative. + +In order to publish your web application, you first need to find the endpoint which will be either an IP +address or a hostname associated with your load balancer. + +To install it, click on the **Install** button for Ingress. GitLab will attempt +to determine the external endpoint and it should be available within a few minutes. + +#### Determining the external endpoint automatically + +> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/17052) in GitLab 10.6. + +After you install Ingress, the external endpoint should be available within a few minutes. + +TIP: **Tip:** +This endpoint can be used for the +[Auto DevOps base domain](../../topics/autodevops/index.md#auto-devops-base-domain) +using the `KUBE_INGRESS_BASE_DOMAIN` environment variable. + +If the endpoint doesn't appear and your cluster runs on Google Kubernetes Engine: + +1. Check your [Kubernetes cluster on Google Kubernetes Engine](https://console.cloud.google.com/kubernetes) to ensure there are no errors on its nodes. +1. Ensure you have enough [Quotas](https://console.cloud.google.com/iam-admin/quotas) on Google Kubernetes Engine. For more information, see [Resource Quotas](https://cloud.google.com/compute/quotas). +1. Check [Google Cloud's Status](https://status.cloud.google.com/) to ensure they are not having any disruptions. + +Once installed, you may see a `?` for "Ingress IP Address" depending on the +cloud provider. For EKS specifically, this is because the ELB is created +with a DNS name, not an IP address. If GitLab is still unable to +determine the endpoint of your Ingress or Knative application, you can +[determine it manually](#determining-the-external-endpoint-manually). + +NOTE: **Note:** The [`stable/nginx-ingress`](https://github.com/helm/charts/tree/master/stable/nginx-ingress) chart is used to install this application with a [`values.yaml`](https://gitlab.com/gitlab-org/gitlab/blob/master/vendor/ingress/values.yaml) file. +#### Determining the external endpoint manually + +If the cluster is on GKE, click the **Google Kubernetes Engine** link in the +**Advanced settings**, or go directly to the +[Google Kubernetes Engine dashboard](https://console.cloud.google.com/kubernetes/) +and select the proper project and cluster. Then click **Connect** and execute +the `gcloud` command in a local terminal or using the **Cloud Shell**. + +If the cluster is not on GKE, follow the specific instructions for your +Kubernetes provider to configure `kubectl` with the right credentials. +The output of the following examples will show the external endpoint of your +cluster. This information can then be used to set up DNS entries and forwarding +rules that allow external access to your deployed applications. + +If you installed Ingress via the **Applications**, run the following command: + +```bash +kubectl get service --namespace=gitlab-managed-apps ingress-nginx-ingress-controller -o jsonpath='{.status.loadBalancer.ingress[0].ip}' +``` + +Some Kubernetes clusters return a hostname instead, like [Amazon EKS](https://aws.amazon.com/eks/). For these platforms, run: + +```bash +kubectl get service --namespace=gitlab-managed-apps ingress-nginx-ingress-controller -o jsonpath='{.status.loadBalancer.ingress[0].hostname}' +``` + +For Istio/Knative, the command will be different: + +```bash +kubectl get svc --namespace=istio-system knative-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip} ' +``` + +Otherwise, you can list the IP addresses of all load balancers: + +```bash +kubectl get svc --all-namespaces -o jsonpath='{range.items[?(@.status.loadBalancer.ingress)]}{.status.loadBalancer.ingress[*].ip} ' +``` + +NOTE: **Note:** +If EKS is used, an [Elastic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/) +will also be created, which will incur additional AWS costs. + +NOTE: **Note:** +You may see a trailing `%` on some Kubernetes versions, **do not include it**. + +The Ingress is now available at this address and will route incoming requests to +the proper service based on the DNS name in the request. To support this, a +wildcard DNS CNAME record should be created for the desired domain name. For example, +`*.myekscluster.com` would point to the Ingress hostname obtained earlier. + +#### Using a static IP + +By default, an ephemeral external IP address is associated to the cluster's load +balancer. If you associate the ephemeral IP with your DNS and the IP changes, +your apps will not be able to be reached, and you'd have to change the DNS +record again. In order to avoid that, you should change it into a static +reserved IP. + +Read how to [promote an ephemeral external IP address in GKE](https://cloud.google.com/compute/docs/ip-addresses/reserve-static-external-ip-address#promote_ephemeral_ip). + +#### Pointing your DNS at the external endpoint + +Once you've set up the external endpoint, you should associate it with a [wildcard DNS +record](https://en.wikipedia.org/wiki/Wildcard_DNS_record) such as `*.example.com.` +in order to be able to reach your apps. If your external endpoint is an IP address, +use an A record. If your external endpoint is a hostname, use a CNAME record. + #### Web Application Firewall (ModSecurity) > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/65192) in GitLab 12.3 (enabled using `ingress_modsecurity` [feature flag](../../development/feature_flags/development.md#enabling-a-feature-flag-in-development)). @@ -259,6 +370,14 @@ chart is used to install this application. open-source monitoring and alerting system useful to supervise your deployed applications. +GitLab is able to monitor applications automatically, using the +[Prometheus integration](../project/integrations/prometheus.md). Kubernetes container CPU and +memory metrics are automatically collected, and response metrics are retrieved +from NGINX Ingress as well. + +To enable monitoring, simply install Prometheus into the cluster with the +**Install** button. + NOTE: **Note:** The [`stable/prometheus`](https://github.com/helm/charts/tree/master/stable/prometheus) chart is used to install this application with a diff --git a/doc/user/packages/npm_registry/index.md b/doc/user/packages/npm_registry/index.md index 5f5d86ab17e..357b7a30591 100644 --- a/doc/user/packages/npm_registry/index.md +++ b/doc/user/packages/npm_registry/index.md @@ -42,6 +42,9 @@ it is not possible due to a naming collision. For example: | `gitlab-org/gitlab` | `@gitlab-org/gitlab` | Yes | | `gitlab-org/gitlab` | `@foo/bar` | No | +CAUTION: **When updating the path of a user/group or transferring a (sub)group/project:** +If you update the root namespace of a project with NPM packages, your changes will be rejected. To be allowed to do that, make sure to remove any NPM package first. Don't forget to update your `.npmrc` files to follow the above naming convention and run `npm publish` if necessary. + Now, you can configure your project to authenticate with the GitLab NPM Registry. diff --git a/doc/user/project/clusters/img/create_dns.png b/doc/user/project/clusters/img/create_dns.png Binary files differdeleted file mode 100644 index 61ed85e5cd9..00000000000 --- a/doc/user/project/clusters/img/create_dns.png +++ /dev/null diff --git a/doc/user/project/clusters/img/deploy_apps.png b/doc/user/project/clusters/img/deploy_apps.png Binary files differdeleted file mode 100644 index 0d9fcc838d9..00000000000 --- a/doc/user/project/clusters/img/deploy_apps.png +++ /dev/null diff --git a/doc/user/project/clusters/index.md b/doc/user/project/clusters/index.md index fc946fc785c..1867b9c0198 100644 --- a/doc/user/project/clusters/index.md +++ b/doc/user/project/clusters/index.md @@ -218,149 +218,12 @@ differentiate the new cluster with the rest. ## Installing applications -GitLab can install and manage some applications in your project-level -cluster. For more information on installing, upgrading, uninstalling, -and troubleshooting applications for your project cluster, see +GitLab can install and manage some applications like Helm, GitLab Runner, Ingress, +Prometheus, etc., in your project-level cluster. For more information on +installing, upgrading, uninstalling, and troubleshooting applications for +your project cluster, see [GitLab Managed Apps](../../clusters/applications.md). -### Getting the external endpoint - -NOTE: **Note:** -With the following procedure, a load balancer must be installed in your cluster -to obtain the endpoint. You can use either -[Ingress](#installing-applications), or Knative's own load balancer -([Istio](https://istio.io)) if using [Knative](#installing-applications). - -In order to publish your web application, you first need to find the endpoint which will be either an IP -address or a hostname associated with your load balancer. - -#### Automatically determining the external endpoint - -> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/17052) in GitLab 10.6. - -After you install [Ingress or Knative](#installing-applications), GitLab attempts to determine the external endpoint -and it should be available within a few minutes. If the endpoint doesn't appear -and your cluster runs on Google Kubernetes Engine: - -1. Check your [Kubernetes cluster on Google Kubernetes Engine](https://console.cloud.google.com/kubernetes) to ensure there are no errors on its nodes. -1. Ensure you have enough [Quotas](https://console.cloud.google.com/iam-admin/quotas) on Google Kubernetes Engine. For more information, see [Resource Quotas](https://cloud.google.com/compute/quotas). -1. Check [Google Cloud's Status](https://status.cloud.google.com/) to ensure they are not having any disruptions. - -If GitLab is still unable to determine the endpoint of your Ingress or Knative application, you can -manually determine it by following the steps below. - -#### Manually determining the external endpoint - -If the cluster is on GKE, click the **Google Kubernetes Engine** link in the -**Advanced settings**, or go directly to the -[Google Kubernetes Engine dashboard](https://console.cloud.google.com/kubernetes/) -and select the proper project and cluster. Then click **Connect** and execute -the `gcloud` command in a local terminal or using the **Cloud Shell**. - -If the cluster is not on GKE, follow the specific instructions for your -Kubernetes provider to configure `kubectl` with the right credentials. -The output of the following examples will show the external endpoint of your -cluster. This information can then be used to set up DNS entries and forwarding -rules that allow external access to your deployed applications. - -If you installed the Ingress [via the **Applications**](#installing-applications), -run the following command: - -```bash -kubectl get service --namespace=gitlab-managed-apps ingress-nginx-ingress-controller -o jsonpath='{.status.loadBalancer.ingress[0].ip}' -``` - -Some Kubernetes clusters return a hostname instead, like [Amazon EKS](https://aws.amazon.com/eks/). For these platforms, run: - -```bash -kubectl get service --namespace=gitlab-managed-apps ingress-nginx-ingress-controller -o jsonpath='{.status.loadBalancer.ingress[0].hostname}' -``` - -For Istio/Knative, the command will be different: - -```bash -kubectl get svc --namespace=istio-system knative-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip} ' -``` - -Otherwise, you can list the IP addresses of all load balancers: - -```bash -kubectl get svc --all-namespaces -o jsonpath='{range.items[?(@.status.loadBalancer.ingress)]}{.status.loadBalancer.ingress[*].ip} ' -``` - -#### Using a static IP - -By default, an ephemeral external IP address is associated to the cluster's load -balancer. If you associate the ephemeral IP with your DNS and the IP changes, -your apps will not be able to be reached, and you'd have to change the DNS -record again. In order to avoid that, you should change it into a static -reserved IP. - -Read how to [promote an ephemeral external IP address in GKE](https://cloud.google.com/compute/docs/ip-addresses/reserve-static-external-ip-address#promote_ephemeral_ip). - -#### Pointing your DNS at the external endpoint - -Once you've set up the external endpoint, you should associate it with a [wildcard DNS -record](https://en.wikipedia.org/wiki/Wildcard_DNS_record) such as `*.example.com.` -in order to be able to reach your apps. If your external endpoint is an IP address, -use an A record. If your external endpoint is a hostname, use a CNAME record. - -#### Deploy services to the cluster - -GitLab supports one-click deployment of helpful services to the cluster, many of -which support Auto DevOps. Back on the Kubernetes cluster screen in GitLab, a -list of applications is now available to deploy. - -First, install Helm Tiller, a package manager for Kubernetes. This enables -deployment of the other applications. - -![Deploy Apps](img/deploy_apps.png) - -##### Deploying NGINX Ingress (optional) - -Next, if you would like the deployed app to be reachable on the internet, deploy -the Ingress. Note that this will also cause an -[Elastic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/) -to be created, which will incur additional AWS costs. - -Once installed, you may see a `?` for "Ingress IP Address". This is because the -created ELB is available at a DNS name, not an IP address. To get the DNS name, -run: - -```sh -kubectl get service ingress-nginx-ingress-controller -n gitlab-managed-apps -o jsonpath="{.status.loadBalancer.ingress[0].hostname}" -``` - -Note that you may see a trailing `%` on some Kubernetes versions, **do not include it**. - -The Ingress is now available at this address and will route incoming requests to -the proper service based on the DNS name in the request. To support this, a -wildcard DNS CNAME record should be created for the desired domain name. For example, -`*.myekscluster.com` would point to the Ingress hostname obtained earlier. - -![Create DNS](img/create_dns.png) - -##### Deploying the GitLab Runner (optional) - -If the project is on GitLab.com, free shared Runners are available and you do -not have to deploy one. If a project specific Runner is desired, or there are no -shared Runners, it is easy to deploy one. - -Simply click on the **Install** button for the GitLab Runner. It is important to -note that the Runner deployed is set as **privileged**, which means it essentially -has root access to the underlying machine. This is required to build docker images, -and so is on by default. - -##### Deploying Prometheus (optional) - -GitLab is able to monitor applications automatically, utilizing -[Prometheus](../integrations/prometheus.html). Kubernetes container CPU and -memory metrics are automatically collected, and response metrics are retrieved -from NGINX Ingress as well. - -To enable monitoring, simply install Prometheus into the cluster with the -**Install** button. - ## Deploying to a Kubernetes cluster A Kubernetes cluster can be the destination for a deployment job. If diff --git a/doc/user/project/clusters/serverless/index.md b/doc/user/project/clusters/serverless/index.md index e114e8b3ebc..be6371bb1ca 100644 --- a/doc/user/project/clusters/serverless/index.md +++ b/doc/user/project/clusters/serverless/index.md @@ -77,7 +77,7 @@ The minimum recommended cluster size to run Knative is 3-nodes, 6 vCPUs, and 22. ![install-knative](img/install-knative.png) 1. After the Knative installation has finished, you can wait for the IP address or hostname to be displayed in the - **Knative Endpoint** field or [retrieve the Istio Ingress Endpoint manually](../#manually-determining-the-external-endpoint). + **Knative Endpoint** field or [retrieve the Istio Ingress Endpoint manually](../../../clusters/applications.md#determining-the-external-endpoint-manually). NOTE: **Note:** Running `kubectl` commands on your cluster requires setting up access to the cluster first. diff --git a/doc/user/project/integrations/prometheus_library/nginx_ingress.md b/doc/user/project/integrations/prometheus_library/nginx_ingress.md index d630956c109..93f6dbb0302 100644 --- a/doc/user/project/integrations/prometheus_library/nginx_ingress.md +++ b/doc/user/project/integrations/prometheus_library/nginx_ingress.md @@ -30,7 +30,7 @@ For other deployments, there is [some configuration](#manually-setting-up-nginx- ### About managed NGINX Ingress deployments -NGINX Ingress is deployed into the `gitlab-managed-apps` namespace, using the [official Helm chart](https://github.com/helm/charts/tree/master/stable/nginx-ingress). NGINX Ingress will be [externally reachable via the Load Balancer's Endpoint](../../clusters/index.md#getting-the-external-endpoint). +NGINX Ingress is deployed into the `gitlab-managed-apps` namespace, using the [official Helm chart](https://github.com/helm/charts/tree/master/stable/nginx-ingress). NGINX Ingress will be [externally reachable via the Load Balancer's Endpoint](../../../clusters/applications.md#ingress). NGINX is configured for Prometheus monitoring, by setting: diff --git a/doc/user/project/integrations/prometheus_library/nginx_ingress_vts.md b/doc/user/project/integrations/prometheus_library/nginx_ingress_vts.md index 83eac44666c..a1dcb105196 100644 --- a/doc/user/project/integrations/prometheus_library/nginx_ingress_vts.md +++ b/doc/user/project/integrations/prometheus_library/nginx_ingress_vts.md @@ -30,7 +30,7 @@ For other deployments, there is [some configuration](#manually-setting-up-nginx- ### About managed NGINX Ingress deployments -NGINX Ingress is deployed into the `gitlab-managed-apps` namespace, using the [official Helm chart](https://github.com/helm/charts/tree/master/stable/nginx-ingress). NGINX Ingress will be [externally reachable via the Load Balancer's Endpoint](../../clusters/index.md#getting-the-external-endpoint). +NGINX Ingress is deployed into the `gitlab-managed-apps` namespace, using the [official Helm chart](https://github.com/helm/charts/tree/master/stable/nginx-ingress). NGINX Ingress will be [externally reachable via the Load Balancer's Endpoint](../../../clusters/applications.md#ingress). NGINX is configured for Prometheus monitoring, by setting: diff --git a/doc/user/project/pages/getting_started/fork_sample_project.md b/doc/user/project/pages/getting_started/fork_sample_project.md new file mode 100644 index 00000000000..ac1a29ca2a0 --- /dev/null +++ b/doc/user/project/pages/getting_started/fork_sample_project.md @@ -0,0 +1,61 @@ +--- +type: reference, howto +--- + +# New Pages website from a forked sample + +To get started with GitLab Pages from a sample website, the easiest +way to do it is by using one of the [bundled templates](pages_bundled_template.md). +If you don't find one that suits your needs, you can opt by +forking (copying) a [sample project from the most popular Static Site Generators](https://gitlab.com/pages). + +<table class="borderless-table center fixed-table middle width-80"> + <tr> + <td style="width: 30%"><img src="../img/icons/fork.png" alt="Fork" class="image-noshadow half-width"></td> + <td style="width: 10%"> + <strong> + <i class="fa fa-angle-double-right" aria-hidden="true"></i> + </strong> + </td> + <td style="width: 30%"><img src="../img/icons/terminal.png" alt="Deploy" class="image-noshadow half-width"></td> + <td style="width: 10%"> + <strong> + <i class="fa fa-angle-double-right" aria-hidden="true"></i> + </strong> + </td> + <td style="width: 30%"><img src="../img/icons/click.png" alt="Visit" class="image-noshadow half-width"></td> + </tr> + <tr> + <td><em>Fork an example project</em></td> + <td></td> + <td><em>Deploy your website</em></td> + <td></td> + <td><em>Visit your website's URL</em></td> + </tr> +</table> + +**<i class="fa fa-youtube-play youtube" aria-hidden="true"></i> Watch a [video tutorial](https://www.youtube.com/watch?v=TWqh9MtT4Bg) with all the steps below.** + +1. [Fork](../../../../gitlab-basics/fork-project.md) a sample project from the [GitLab Pages examples](https://gitlab.com/pages) group. +1. From the left sidebar, navigate to your project's **CI/CD > Pipelines** + and click **Run pipeline** to trigger GitLab CI/CD to build and deploy your + site to the server. +1. Once the pipeline has finished successfully, find the link to visit your + website from your project's **Settings > Pages**. It can take aproximatelly + 30 minutes to be deployed. + +You can also take some **optional** further steps: + +- _Remove the fork relationship._ The fork relationship is necessary to contribute back to the project you originally forked from. If you don't have any intentions to do so, you can remove it. To do so, navigate to your project's **Settings**, expand **Advanced settings**, and scroll down to **Remove fork relationship**: + + ![remove fork relationship](../img/remove_fork_relationship.png) + +- _Make it a user or group website._ To turn a **project website** forked + from the Pages group into a **user/group** website, you'll need to: + - Rename it to `namespace.gitlab.io`: go to your project's + **Settings > General** and expand **Advanced**. Scroll down to + **Rename repository** and change the path to `namespace.gitlab.io`. + - Adjust your SSG's [base URL](../getting_started_part_one.md#urls-and-baseurls) from `"project-name"` to + `""`. This setting will be at a different place for each SSG, as each of them + have their own structure and file tree. Most likely, it will be in the SSG's + config file. diff --git a/doc/user/project/pages/getting_started/new_or_existing_website.md b/doc/user/project/pages/getting_started/new_or_existing_website.md new file mode 100644 index 00000000000..188b76e4224 --- /dev/null +++ b/doc/user/project/pages/getting_started/new_or_existing_website.md @@ -0,0 +1,45 @@ +--- +type: reference, howto +--- + +# Start a new Pages website from scratch or deploy an exising website + +If you already have a website and want to deploy it with GitLab Pages, +or, if you want to start a new site from scratch, you'll need to: + +- Create a new project in GitLab to hold your site content. +- Set up GitLab CI/CD to deploy your website to Pages. + +To do so, follow the steps below. + +1. From your **Project**'s **[Dashboard](https://gitlab.com/dashboard/projects)**, + click **New project**, and name it according to the + [Pages domain names](../getting_started_part_one.md#gitlab-pages-domain-names). +1. Clone it to your local computer, add your website + files to your project, add, commit and push to GitLab. + Alternativelly, you can run `git init` in your local directory, + add the remote URL: + `git remote add origin git@gitlab.com:namespace/project-name.git`, + then add, commit, and push to GitLab. +1. From the your **Project**'s page, click **Set up CI/CD**: + + ![setup GitLab CI/CD](../img/setup_ci.png) + +1. Choose one of the templates from the dropbox menu. + Pick up the template corresponding to the SSG you're using (or plain HTML). + + ![gitlab-ci templates](../img/choose_ci_template.png) + + Note that, if you don't find a corresponding template, you can look into + [GitLab Pages group of sample projects](https://gitlab.com/pages), + you may find one among them that suits your needs, from which you + can copy `.gitlab-ci.yml`'s content and adjust for your case. + If you don't find it there either, [learn how to write a `.gitlab-ci.yml` + file for GitLab Pages](../getting_started_part_four.md). + +Once you have both site files and `.gitlab-ci.yml` in your project's +root, GitLab CI/CD will build your site and deploy it with Pages. +Once the first build passes, you access your site by +navigating to your **Project**'s **Settings** > **Pages**, +where you'll find its default URL. It can take approximately 30 min to be +deployed. diff --git a/doc/user/project/pages/getting_started/pages_bundled_template.md b/doc/user/project/pages/getting_started/pages_bundled_template.md new file mode 100644 index 00000000000..802abeb3cc2 --- /dev/null +++ b/doc/user/project/pages/getting_started/pages_bundled_template.md @@ -0,0 +1,29 @@ +--- +type: reference, howto +--- + +# New Pages website from a bundled template + +> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/47857) +in GitLab 11.8. + +The simplest way to create a GitLab Pages site is to use one of the most +popular templates, which come already bundled with GitLab and are ready to go. + +1. From the top navigation, click the **+** button and select **New project**. +1. Select **Create from Template**. +1. Choose one of the templates starting with **Pages**: + + ![Project templates for Pages](../img/pages_project_templates_v11_8.png) + +1. From the left sidebar, navigate to your project's **CI/CD > Pipelines** + and click **Run pipeline** to trigger GitLab CI/CD to build and deploy your + site to the server. +1. After the pipeline has finished successfully, wait approximately 30 minutes + for your website to be visible. After waiting 30 minutes, find the link to + visit your website from your project's **Settings > Pages**. If the link + leads to a 404 page, wait a few minutes and try again. + +Your website is then visible on your domain and you can modify your files +as you wish. For every modification pushed to your repository, GitLab CI/CD +will run a new pipeline to immediately publish your changes to the server. diff --git a/doc/user/project/pages/getting_started_part_one.md b/doc/user/project/pages/getting_started_part_one.md index 0b1cae9ab4c..f9169fba220 100644 --- a/doc/user/project/pages/getting_started_part_one.md +++ b/doc/user/project/pages/getting_started_part_one.md @@ -3,24 +3,11 @@ last_updated: 2018-06-04 type: concepts, reference --- -# Static sites and GitLab Pages domains +# GitLab Pages domain names, URLs, and baseurls On this document, learn how to name your project for GitLab Pages according to your intended website's URL. -## Static sites - -GitLab Pages only supports static websites, meaning, -your output files must be HTML, CSS, and JavaScript only. - -To create your static site, you can either hardcode in HTML, -CSS, and JS, or use a [Static Site Generator (SSG)](https://www.staticgen.com/) -to simplify your code and build the static site for you, -which is highly recommendable and much faster than hardcoding. - -See the [further reading](#further-reading) section below for -references on static site concepts. - ## GitLab Pages domain names >**Note:** @@ -93,11 +80,35 @@ To understand Pages domains clearly, read the examples below. - On your GitLab instance, replace `gitlab.io` above with your Pages server domain. Ask your sysadmin for this information. -_Read on about [Projects for GitLab Pages and URL structure](getting_started_part_two.md)._ +## URLs and Baseurls + +Every Static Site Generator (SSG) default configuration expects +to find your website under a (sub)domain (`example.com`), not +in a subdirectory of that domain (`example.com/subdir`). Therefore, +whenever you publish a project website (`namespace.gitlab.io/project-name`), +you'll have to look for this configuration (base URL) on your SSG's +documentation and set it up to reflect this pattern. + +For example, for a Jekyll site, the `baseurl` is defined in the Jekyll +configuration file, `_config.yml`. If your website URL is +`https://john.gitlab.io/blog/`, you need to add this line to `_config.yml`: + +```yaml +baseurl: "/blog" +``` + +On the contrary, if you deploy your website after forking one of +our [default examples](https://gitlab.com/pages), the baseurl will +already be configured this way, as all examples there are project +websites. If you decide to make yours a user or group website, you'll +have to remove this configuration from your project. For the Jekyll +example we've just mentioned, you'd have to change Jekyll's `_config.yml` to: + +```yaml +baseurl: "" +``` -### Further reading +## Custom Domains -- Read through this technical overview on [Static versus Dynamic Websites](https://about.gitlab.com/blog/2016/06/03/ssg-overview-gitlab-pages-part-1-dynamic-x-static/) -- Understand [how modern Static Site Generators work](https://about.gitlab.com/blog/2016/06/10/ssg-overview-gitlab-pages-part-2/) and what you can add to your static site -- You can use [any SSG with GitLab Pages](https://about.gitlab.com/blog/2016/06/17/ssg-overview-gitlab-pages-part-3-examples-ci/) -- Fork an [example project](https://gitlab.com/pages) to build your website based upon +GitLab Pages supports custom domains and subdomains, served under HTTP or HTTPS. +See [GitLab Pages custom domains and SSL/TLS Certificates](custom_domains_ssl_tls_certification/index.md) for more information. diff --git a/doc/user/project/pages/getting_started_part_two.md b/doc/user/project/pages/getting_started_part_two.md index ff752917087..70e84f5d486 100644 --- a/doc/user/project/pages/getting_started_part_two.md +++ b/doc/user/project/pages/getting_started_part_two.md @@ -1,172 +1,5 @@ --- -last_updated: 2019-06-04 -type: reference, howto +redirect_to: 'index.md' --- -# Projects for GitLab Pages and URL structure - -## What you need to get started - -To get started with GitLab Pages, you need: - -1. A project, thus a repository to hold your website's codebase. -1. A configuration file (`.gitlab-ci.yml`) to deploy your site. -1. A specific `job` called `pages` in the configuration file - that will make GitLab aware that you are deploying a GitLab Pages website. -1. A `public` directory with the static content of the website. - -Optional Features: - -1. A custom domain or subdomain. -1. A DNS pointing your (sub)domain to your Pages site. - 1. **Optional**: an SSL/TLS certificate so your custom - domain is accessible under HTTPS. - -The optional settings, custom domain, DNS records, and SSL/TLS certificates, are described in [GitLab Pages custom domains and SSL/TLS Certificates](custom_domains_ssl_tls_certification/index.md)). - -## Project - -Your GitLab Pages project is a regular project created the -same way you do for the other ones. To get started with GitLab Pages, you have three ways: - -- [Use one of the popular project templates bundled with GitLab](#use-one-of-the-popular-pages-templates-bundled-with-gitlab). -- [Fork one of the templates from Page Examples](#fork-a-project-to-get-started-from). -- [Create a new project from scratch](#create-a-project-from-scratch). - -### Use one of the popular Pages templates bundled with GitLab - -> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/47857) -in GitLab 11.8. - -The simplest way to create a GitLab Pages site is to -[use one of the most popular templates](index.md#getting-started), -which come already bundled with GitLab and are ready to go. - -### Fork a project to get started from - -If you don't find an existing project template that suits you, -we've created this [group](https://gitlab.com/pages) of default projects -containing the most popular SSGs templates to get you started. - -<table class="borderless-table center fixed-table middle width-80"> - <tr> - <td style="width: 30%"><img src="img/icons/fork.png" alt="Fork" class="image-noshadow half-width"></td> - <td style="width: 10%"> - <strong> - <i class="fa fa-angle-double-right" aria-hidden="true"></i> - </strong> - </td> - <td style="width: 30%"><img src="img/icons/terminal.png" alt="Deploy" class="image-noshadow half-width"></td> - <td style="width: 10%"> - <strong> - <i class="fa fa-angle-double-right" aria-hidden="true"></i> - </strong> - </td> - <td style="width: 30%"><img src="img/icons/click.png" alt="Visit" class="image-noshadow half-width"></td> - </tr> - <tr> - <td><em>Fork an example project</em></td> - <td></td> - <td><em>Deploy your website</em></td> - <td></td> - <td><em>Visit your website's URL</em></td> - </tr> -</table> - -**<i class="fa fa-youtube-play youtube" aria-hidden="true"></i> Watch a [video tutorial](https://www.youtube.com/watch?v=TWqh9MtT4Bg) with all the steps below.** - -1. [Fork](../../../gitlab-basics/fork-project.md) a sample project from the [GitLab Pages examples](https://gitlab.com/pages) group. -1. From the left sidebar, navigate to your project's **CI/CD > Pipelines** - and click **Run pipeline** to trigger GitLab CI/CD to build and deploy your - site to the server. -1. Once the pipeline has finished successfully, find the link to visit your - website from your project's **Settings > Pages**. - -You can also take some **optional** further steps: - -- _Remove the fork relationship._ The fork relationship is necessary to contribute back to the project you originally forked from. If you don't have any intentions to do so, you can remove it. To do so, navigate to your project's **Settings**, expand **Advanced settings**, and scroll down to **Remove fork relationship**: - - ![remove fork relationship](img/remove_fork_relationship.png) - -- _Make it a user or group website._ To turn a **project website** forked - from the Pages group into a **user/group** website, you'll need to: - - Rename it to `namespace.gitlab.io`: go to your project's - **Settings > General** and expand **Advanced**. Scroll down to - **Rename repository** and change the path to `namespace.gitlab.io`. - - Adjust your SSG's [base URL](#urls-and-baseurls) from `"project-name"` to - `""`. This setting will be at a different place for each SSG, as each of them - have their own structure and file tree. Most likely, it will be in the SSG's - config file. - -### Create a project from scratch - -1. From your **Project**'s **[Dashboard](https://gitlab.com/dashboard/projects)**, - click **New project**, and name it according to the - [Pages domain names](getting_started_part_one.md#gitlab-pages-domain-names). -1. Clone it to your local computer, add your website - files to your project, add, commit and push to GitLab. -1. From the your **Project**'s page, click **Set up CI/CD**: - - ![setup GitLab CI/CD](img/setup_ci.png) - -1. Choose one of the templates from the dropbox menu. - Pick up the template corresponding to the SSG you're using (or plain HTML). - - ![gitlab-ci templates](img/choose_ci_template.png) - -Once you have both site files and `.gitlab-ci.yml` in your project's -root, GitLab CI/CD will build your site and deploy it with Pages. -Once the first build passes, you see your site is live by -navigating to your **Project**'s **Settings** > **Pages**, -where you'll find its default URL. - -> **Notes:** -> -> - GitLab Pages [supports any SSG](https://about.gitlab.com/blog/2016/06/17/ssg-overview-gitlab-pages-part-3-examples-ci/), but, -> if you don't find yours among the templates, you'll need -> to configure your own `.gitlab-ci.yml`. To do that, please -> read through the article [Creating and Tweaking GitLab CI/CD for GitLab Pages](getting_started_part_four.md). New SSGs are very welcome among -> the [example projects](https://gitlab.com/pages). If you set -> up a new one, please -> [contribute](https://gitlab.com/pages/pages.gitlab.io/blob/master/CONTRIBUTING.md) -> to our examples. -> -> - The second step _"Clone it to your local computer"_, can be done -> differently, achieving the same results: instead of cloning the bare -> repository to you local computer and moving your site files into it, -> you can run `git init` in your local website directory, add the -> remote URL: `git remote add origin git@gitlab.com:namespace/project-name.git`, -> then add, commit, and push to GitLab. - -## URLs and Baseurls - -Every Static Site Generator (SSG) default configuration expects -to find your website under a (sub)domain (`example.com`), not -in a subdirectory of that domain (`example.com/subdir`). Therefore, -whenever you publish a project website (`namespace.gitlab.io/project-name`), -you'll have to look for this configuration (base URL) on your SSG's -documentation and set it up to reflect this pattern. - -For example, for a Jekyll site, the `baseurl` is defined in the Jekyll -configuration file, `_config.yml`. If your website URL is -`https://john.gitlab.io/blog/`, you need to add this line to `_config.yml`: - -```yaml -baseurl: "/blog" -``` - -On the contrary, if you deploy your website after forking one of -our [default examples](https://gitlab.com/pages), the baseurl will -already be configured this way, as all examples there are project -websites. If you decide to make yours a user or group website, you'll -have to remove this configuration from your project. For the Jekyll -example we've just mentioned, you'd have to change Jekyll's `_config.yml` to: - -```yaml -baseurl: "" -``` - -## Custom Domains - -GitLab Pages supports custom domains and subdomains, served under HTTP or HTTPS. -See [GitLab Pages custom domains and SSL/TLS Certificates](custom_domains_ssl_tls_certification/index.md) for more information. +This document was moved to [another location](index.md#getting-started). diff --git a/doc/user/project/pages/index.md b/doc/user/project/pages/index.md index 7d533c6f9d1..d59c2e4fdf3 100644 --- a/doc/user/project/pages/index.md +++ b/doc/user/project/pages/index.md @@ -73,6 +73,7 @@ publish any website written directly in plain HTML, CSS, and JavaScript.</p> To use GitLab Pages, first you need to create a project in GitLab to upload your website's files to. These projects can be either public, internal, or private, at your own choice. + GitLab will always deploy your website from a very specific folder called `public` in your repository. Note that when you create a new project in GitLab, a [repository](../repository/index.md) becomes available automatically. @@ -80,67 +81,48 @@ becomes available automatically. To deploy your site, GitLab will use its built-in tool called [GitLab CI/CD](../../../ci/README.md), to build your site and publish it to the GitLab Pages server. The sequence of scripts that GitLab CI/CD runs to accomplish this task is created from a file named -`.gitlab-ci.yml`, which you can [create and modify](getting_started_part_four.md) at will. +`.gitlab-ci.yml`, which you can [create and modify](getting_started_part_four.md) at will. A specific `job` called `pages` in the configuration file will make GitLab aware that you are deploying a GitLab Pages website. You can either use GitLab's [default domain for GitLab Pages websites](getting_started_part_one.md#gitlab-pages-domain-names), `*.gitlab.io`, or your own domain (`example.com`). In that case, you'll need admin access to your domain's registrar (or control panel) to set it up with Pages. -Optionally, when adding your own domain, you can add an SSL/TLS certificate to secure your -site under the HTTPS protocol. - ### Getting started To get started with GitLab Pages, you can either: -- [Create a project from scratch](getting_started_part_two.md#create-a-project-from-scratch). -- [Copy an existing example project](getting_started_part_two.md#fork-a-project-to-get-started-from). -- Use a bundled project template ready to go: - -1. From the top navigation, click the **+** button and select **New project**. -1. Select **Create from Template**. -1. Choose one of the templates starting with **Pages**: - - ![Project templates for Pages](img/pages_project_templates_v11_8.png) +- [Use a bundled website template ready to go](getting_started/pages_bundled_template.md). +- [Copy an existing sample](getting_started/fork_sample_project.md). +- [Create a website from scratch or deploy an existing one](getting_started/new_or_existing_website.md). -1. From the left sidebar, navigate to your project's **CI/CD > Pipelines** - and click **Run pipeline** to trigger GitLab CI/CD to build and deploy your - site to the server. -1. After the pipeline has finished successfully, wait approximately 30 minutes - for your website to be visible. After waiting 30 minutes, find the link to - visit your website from your project's **Settings > Pages**. If the link - leads to a 404 page, wait a few minutes and try again. +Optional features: -Your website is then visible on your domain and you can modify your files -as you wish. For every modification pushed to your repository, GitLab CI/CD -will run a new pipeline to immediately publish your changes to the server. +- Use a [custom domain or subdomain](custom_domains_ssl_tls_certification/index.md#set-up-pages-with-a-custom-domain). +- Add an [SSL/TLS certificate to secure your site under the HTTPS protocol](custom_domains_ssl_tls_certification/index.md#adding-an-ssltls-certificate-to-pages). -_Advanced options:_ - -- [Use a custom domain](custom_domains_ssl_tls_certification/index.md#set-up-pages-with-a-custom-domain) -- Apply [SSL/TLS certification](custom_domains_ssl_tls_certification/index.md#adding-an-ssltls-certificate-to-pages) to your custom domain +Note that, if you're using GitLab Pages default domain (`.gitlab.io`), +your website will be automatically secure and available under +HTTPS. If you're using your own custom domain, you can +optionally secure it with SSL/TLS certificates. ## Availability If you're using GitLab.com, your website will be publicly available to the internet. + +To restrict access to your website, enable [GitLab Pages Access Control](pages_access_control.md). + If you're using self-managed instances (Core, Starter, Premium, or Ultimate), your websites will be published on your own server, according to the [Pages admin settings](../../../administration/pages/index.md) chosen by your sysadmin, who can opt for making them public or internal to your server. -Note that, if you're using GitLab Pages default domain (`.gitlab.io`), -your website will be automatically secure and available under -HTTPS. If you're using your own custom domain, you can -optionally secure it with SSL/TLS certificates. - ## Explore GitLab Pages To learn more about configuration options for GitLab Pages, read the following: | Document | Description | | --- | --- | -| [Static websites and Pages domains](getting_started_part_one.md) | Understand what is a static website, and how GitLab Pages default domains work. | -| [Projects and URL structure](getting_started_part_two.md) | Forking projects and creating new ones from scratch, understanding URLs structure and baseurls. | +| [GitLab Pages domain names, URLs, and baseurls](getting_started_part_one.md) | Understand how GitLab Pages default domains work. | | [GitLab CI/CD for GitLab Pages](getting_started_part_four.md) | Understand how to create your own `.gitlab-ci.yml` for your site. | | [Exploring GitLab Pages](introduction.md) | Requirements, technical aspects, specific GitLab CI's configuration options, Access Control, custom 404 pages, limitations, FAQ. | |---+---| diff --git a/doc/user/project/pages/introduction.md b/doc/user/project/pages/introduction.md index 86257e2aa03..01e1909f6d6 100644 --- a/doc/user/project/pages/introduction.md +++ b/doc/user/project/pages/introduction.md @@ -69,40 +69,7 @@ don't have to create and edit HTML files manually. For example, Jekyll has the ## GitLab Pages Access Control **(CORE)** -> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/33422) in GitLab 11.5. - -You can enable Pages access control on your project, so that only -[members of your project](../../permissions.md#project-members-permissions) -(at least Guest) can access your website: - -1. Navigate to your project's **Settings > General > Permissions**. -1. Toggle the **Pages** button to enable the access control. - - NOTE: **Note:** - If you don't see the toggle button, that means that it's not enabled. - Ask your administrator to [enable it](../../../administration/pages/index.md#access-control). - -1. The Pages access control dropdown allows you to set who can view pages hosted - with GitLab Pages, depending on your project's visibility: - - - If your project is private: - - **Only project members**: Only project members will be able to browse the website. - - **Everyone**: Everyone, both logged into and logged out of GitLab, will be able to browse the website, no matter their project membership. - - If your project is internal: - - **Only project members**: Only project members will be able to browse the website. - - **Everyone with access**: Everyone logged into GitLab will be able to browse the website, no matter their project membership. - - **Everyone**: Everyone, both logged into and logged out of GitLab, will be able to browse the website, no matter their project membership. - - If your project is public: - - **Only project members**: Only project members will be able to browse the website. - - **Everyone with access**: Everyone, both logged into and logged out of GitLab, will be able to browse the website, no matter their project membership. - -1. Click **Save changes**. - ---- - -The next time someone tries to access your website and the access control is -enabled, they will be presented with a page to sign into GitLab and verify they -can access the website. +To restrict access to your website, enable [GitLab Pages Access Control](pages_access_control.md). ## Unpublishing your Pages diff --git a/doc/user/project/pages/lets_encrypt_for_gitlab_pages.md b/doc/user/project/pages/lets_encrypt_for_gitlab_pages.md index 1338c7e58f5..c9bd3e35a5f 100644 --- a/doc/user/project/pages/lets_encrypt_for_gitlab_pages.md +++ b/doc/user/project/pages/lets_encrypt_for_gitlab_pages.md @@ -21,8 +21,8 @@ open source Certificate Authority. To follow along with this tutorial, we assume you already have: -- Created a [project](getting_started_part_two.md) in GitLab which - contains your website's source code. +- [Created a project](index.md#getting-started) in GitLab + containing your website's source code. - Acquired a domain (`example.com`) and added a [DNS entry](custom_domains_ssl_tls_certification/index.md#set-up-pages-with-a-custom-domain) pointing it to your Pages website. - [Added your domain to your Pages project](custom_domains_ssl_tls_certification/index.md#steps) diff --git a/doc/user/project/pages/pages_access_control.md b/doc/user/project/pages/pages_access_control.md new file mode 100644 index 00000000000..cd715c6e3b9 --- /dev/null +++ b/doc/user/project/pages/pages_access_control.md @@ -0,0 +1,48 @@ +--- +type: reference, howto +--- + +# GitLab Pages Access Control + +> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/33422) in GitLab 11.5. +> - Available on GitLab.com in GitLab 12.4. + +You can enable Pages access control on your project, so that only +[members of your project](../../permissions.md#project-members-permissions) +(at least Guest) can access your website: + +1. Navigate to your project's **Settings > General > Permissions**. +1. Toggle the **Pages** button to enable the access control. + + NOTE: **Note:** + If you don't see the toggle button, that means that it's not enabled. + Ask your administrator to [enable it](../../../administration/pages/index.md#access-control). + +1. The Pages access control dropdown allows you to set who can view pages hosted + with GitLab Pages, depending on your project's visibility: + + - If your project is private: + - **Only project members**: Only project members will be able to browse the website. + - **Everyone**: Everyone, both logged into and logged out of GitLab, will be able to browse the website, no matter their project membership. + - If your project is internal: + - **Only project members**: Only project members will be able to browse the website. + - **Everyone with access**: Everyone logged into GitLab will be able to browse the website, no matter their project membership. + - **Everyone**: Everyone, both logged into and logged out of GitLab, will be able to browse the website, no matter their project membership. + - If your project is public: + - **Only project members**: Only project members will be able to browse the website. + - **Everyone with access**: Everyone, both logged into and logged out of GitLab, will be able to browse the website, no matter their project membership. + +1. Click **Save changes**. + +The next time someone tries to access your website and the access control is +enabled, they will be presented with a page to sign into GitLab and verify they +can access the website. + +## Terminating a Pages session + +If you want to log out from your Pages website, +you can do so by revoking application access token for GitLab Pages: + +1. Navigate to your profile's **Settings > Applications**. +1. Find **Authorized applications** at the bottom of the page. +1. Find **GitLab Pages** and press the **Revoke** button. |