GKE — Issuer DNS01

 

В качестве DNS Provider‘а будет выступать GCP.

 

YOUR_GCP_PROJECT — Замените на имя своего GCP проекта

 

Создаем аккаунт:

gcloud iam service-accounts create dns01-solver \
 --display-name "dns01-solver"

 

Предоставляем ему доступ к DNS сервису:

gcloud projects add-iam-policy-binding YOUR_GCP_PROJECT \
 --member serviceAccount:dns01-solver@YOUR_GCP_PROJECT.iam.gserviceaccount.com \
 --role roles/dns.

 

Генерируем ключ:

gcloud iam service-accounts keys create key.json \
 --iam-account dns01-solver@YOUR_GCP_PROJECT.iam.gserviceaccount.com

 

Создаем секрет на основе сгенерированного ключа:

kubectl create secret generic clouddns-dns01-solver-svc-acct -n cert-manager \
 --from-file=key.json

 

Создаем 2 YAML файла для ClusterIssuer.

 

letsencrypt-staging.yml

apiVersion: certmanager.k8s.io/v1alpha1
kind: ClusterIssuer
metadata:
  name: letsencrypt-staging
spec:
  acme:
    # The ACME server URL
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    # Email address used for ACME registration
    email: [email protected]
    # Name of a secret used to store the ACME account private key
    privateKeySecretRef:
      name: letsencrypt-staging
    solvers:
    - dns01:
        clouddns:
          # The ID of the GCP project
          project: YOUR_GCP_PROJECT
          # This is the secret used to access the service account
          serviceAccountSecretRef:
            name: clouddns-dns01-solver-svc-acct
            key: key.json

 

letsencrypt-production.yml

apiVersion: certmanager.k8s.io/v1alpha1
kind: ClusterIssuer
metadata:
  name: letsencrypt-production
  namespace: cert-manager
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    # This will register an issuer with LetsEncrypt.  Replace
    # with your admin email address.
    email: [email protected]
    privateKeySecretRef:
      # Set privateKeySecretRef to any unused secret name.
      name: letsencrypt-production
    dns01:
      providers:
      - name: dns
        clouddns:
          # Set this to your GCP project-id
          project: YOUR_GCP_PROJECT
          # Set this to the secret that we publish our service account key
          # in the previous step.
          serviceAccountSecretRef:
            name: clouddns-dns01-solver-svc-acct
            key: key.json

 

Не забываем указать имя своего GCP проекта и почтовый ящик.

 

Создаем ClusterIssuer:

kubectl create -f letsencrypt-staging.yml
kubectl create -f letsencrypt-production.yml

 

 

Пример Ingress‘а:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx
    certmanager.k8s.io/cluster-issuer: letsencrypt-production
    certmanager.k8s.io/acme-challenge-type: dns01
    certmanager.k8s.io/acme-dns01-provider: dns
  name: artem-service-ing
  namespace: staging
spec:
  tls:
  - hosts:
    - artem.services
    secretName: artem.services-tls
  rules:
  - host: artem.services
    http:
      paths:
      - path: /
        backend:
          serviceName: artem-services-svc
          servicePort: 80

 

artem-services-svc — имя сервиса
80 — порт сервиса

GKE — Установка Cert Manager используя HELM

Инструкцию по установке можно найти тут.

 

Выполняем:

kubectl apply -f https://raw.githubusercontent.com/jetstack/cert-manager/release-0.8/deploy

kubectl label namespace cert-manager certmanager.k8s.io/disable-validation="true"

 

Если неймспейса нет, то создаем.

 

Добавляем HELM репозиторий и обновляем:

helm repo add jetstack https://charts.jetstack.io

helm repo update

 

Устанавливаем Cert Manager с помощью HELM‘а:

helm install \
  --name cert-manager \
  --namespace cert-manager \
  --version v0.8.1 \
  jetstack/cert-manager

Linux — Восстановление стандартных прав на файлы и директории

 

Найдем все директории, которые находятся по пути «/home/artem» и установим им стандартные права на директорию «755«, так же найдем все файлы и установим права «644»

find /home/artem -type d -exec chmod 755 {} \;
find /home/artem -type f -exec chmod 644 {} \;

 

Не все директории используют права «755«, к примеру для директории «.ssh» необходимы права «600«

FIX ERROR — WordPress: Blocked loading mixed active content

Подобная ошибка может возникнуть при использовании смешанного контента HTTP и HTTPS.

Blocked loading mixed active content

 

Решение:

Чтобы от нее избавится и все загрузить использую протокол HTTPS, необходимо в файл «wp-config.php» добавить следующее:

$_SERVER['HTTPS'] = 'on';

GKE — Установка Nginx Ingress используя HELM

 

Инструкцию по установке можно найти тут.

 

Устанавливаем HELM локально:

curl -o get_helm.sh https://raw.githubusercontent.com/kubernetes/helm/master/scripts/get
chmod +x get_helm.sh
./get_helm.sh

helm init

 

Устанавливаем Tiller с включенным RBAC

Начиная с Kubernetes v1.8+, RBAC включен по умолчанию.

 

kubectl create serviceaccount --namespace kube-system tiller
kubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tiller
helm init --service-account tiller

 

Проверяем:

kubectl get deployments -n kube-system | grep tiller

 

Создаем Nginx Ingress Controller:

helm install --name nginx-ingress stable/nginx-ingress --set rbac.create=true --set controller.publishService.enabled=true

 

Если возникла такая ошибка:

Error: release nginx-ingress failed: namespaces "default" is forbidden: User "system:serviceaccount:kube-system:default" cannot get resource "namespaces" in API group "" in the namespace "default"

 

Выполните следующее:

helm init --service-account tiller --upgrade

 

Смотрим внешний IP адрес Ingress‘а:

kubectl --namespace default get services -o wide -w nginx-ingress-controller

 

Его можно сразу зарезервировать.

Kubernetes — Status: Evicted

Статус «Evicted» означает, что Pod был «выселен» с ноды, так как ему не хватило ресурсов. Это можно наблюдать, если вывести поды:

kubectl get pod -n staging
NAME                                      READY   STATUS             RESTARTS   AGE
artem-client-app-5bb855b7-ccfmz           1/1     Running            0          63m
artem-instance-app-64584c56d4-4g5qh       0/1     Evicted            0          16m
artem-instance-app-64584c56d4-knc9z       0/1     Evicted            0          16m
artem-instance-app-64584c56d4-ld8h9       0/1     Evicted            0          25m
artem-instance-app-64584c56d4-lstt9       0/1     Evicted            0          16m
artem-instance-app-64584c56d4-sksrg       0/1     Evicted            0          16m
artem-instance-app-c67d9b8b9-7ppsg        1/1     Running            0          14m

 

Для того, чтобы удалить все поды в статусе «Evicted» выполните следующее:

kubectl get pods --all-namespaces -o json | jq '.items[] | select(.status.reason!=null) | select(.status.reason | contains("Evicted")) | "kubectl delete pods \(.metadata.name) -n \(.metadata.namespace)"' | xargs -n 1 bash -c

Kubernetes — CORS enable

Для включения CORS в ingress добавим следующее:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    ...
    nginx.ingress.kubernetes.io/enable-cors: "true"
    nginx.ingress.kubernetes.io/cors-allow-methods: "PUT, GET, POST, OPTIONS"
    nginx.ingress.kubernetes.io/cors-allow-origin: "*"
    nginx.ingress.kubernetes.io/cors-allow-credentials: "true"

 

* — разрешает запросы отовсюду, замените ее на нужный вам домен

FIX ERROR — phpMyAdmin+Apache 2.4: client denied by server configuration: /usr/share/phpMyAdmin/

При попытке зайти на phpMyAdmin используя Apache 2.4 получил 403-ую ошибку, в логах следующее сообщение:

client denied by server configuration: /usr/share/phpMyAdmin/

Причина тому, что конфигурация для Apache версии 2.2

 

Решение:

Открываем файл конфигурации:

vim /etc/httpd/conf.d/phpMyAdmin.conf

 

И меняем эту часть:

<Directory /usr/share/phpMyAdmin/>
   AddDefaultCharset UTF-8

 

На следующее:

<Directory /usr/share/phpMyAdmin/>
   AddDefaultCharset UTF-8
   Options Indexes FollowSymLinks MultiViews
   DirectoryIndex index.php
   AllowOverride all
   Require all granted

 

Перезапускаем сервис httpd:

<Directory /usr/share/phpMyAdmin/>
systemctl restart httpd

FIX ERROR — WordPress: The server requested authentication method unknown to the client [caching_sha2_password]

При установке WordPress‘а при использовании MySQL 8 может возникнуть следующая ошибка:

Warning: mysqli_real_connect(): The server requested authentication method unknown to the client [caching_sha2_password]

Причина в методе авторизации по умолчанию.

 

Решение:

В файл «/etc/my.cnf» в блок «mysqld» добавить следующее:

default-authentication-plugin=mysql_native_password

 

И перезапускаем сервис mysqld:

systemctl restart mysqld

 

Если пользователь был уже создан при использовании метода «caching_sha2_password«, то нужно залогиниться в mysql и выполнить следующее:

alter user 'username'@'localhost' identified with mysql_native_password by 'password';