GitHub Pages — отличный способ разместить сервер

Страницы GitHub

В последнее время я часто использую страницы github и рекомендую всем, кто ими не пользуется, начать их использовать. .

Это избавляет вас от хлопот, связанных с приобретением оборудования для размещения сервера, масштабированием, если у вас много пользователей (не то, что я делаю), и общей доступностью, которой вы обычно не получаете при работе на заводе. домашние серверы.

На самом деле я размещаю этот блог на страницах GH, и это очень просто с действием github. Вот тот, который я использую для продвижения этого блога на страницы GH

```yaml title=".github/workflows/main.yaml" имя: КИ на: толкать: ветки: [главная]

Устанавливает разрешения GITHUB_TOKEN, чтобы разрешить развертывание на страницах GitHub

разрешения: содержание: читать страницы: написать id-токен: написать

Разрешить одно одновременное развертывание

параллелизм: группа: "страницы" отмена в процессе: правда

работы: дом: запуски: ubuntu-последняя среда: имя: github-страницы URL-адрес: ${{steps.deployment.outputs.page_url}} шаги: - использует: action/checkout@v3 - имя: Использовать Node.js 18 использует: action/setup-node@v2 с: нод-версия: 18 - имя: установка и сборка npm запустить: | установка нпм npm запустить сборку - название: Страницы настройки использует: action/configure-pages@v2 - имя: Загрузить артефакт использует: action/upload-pages-artifact@v1 с: # Загрузить весь репозиторий путь: './сборка' - имя: Развернуть на страницах GitHub идентификатор: развертывание использует: action/deploy-pages@v1

But this post is not really about GH pages, it is rather about what to do when you can't use it.

## Serverless backends

So I was writing a time reporting page, because who doesn't love to do time reporting in tons of places! The plan was to make it sync with github gists, but the problem I ran into was that my frontend couldn't read gists without cors issues. The solution to this was to host a server that can proxy the requests to the frontend.


Now the issue with that is that I have a bad habbit of creating hobby projects that plain and simply wastes resources by being up all the time.


It might not be a lot, since a node server with no traffic doesn't eat a lot of ram and it doesn't take that much CPU, but it still hurts me a bit to have them just lay there doing nothing.


What I could do to mitigate this is just do a "regular" kubernetes deployment and scale it down to zero when it is not needed, but I fear that one day when I do need it, and I have no access to my cluster to scale it up.


The sane approach is to start using AWS lambda, Azure functions or google cloud functions, as they also scale to zero and cost next to nothing, with the addition of being highly available... but that is not the approach I went with. Instead I installed knative in my k8s cluster.

## Knative

[Knative](https://knative.dev/docs/) is a k8s controller which gives you "serverless" properties on your k8s cluster. Of course it is not serverless as you need your own k8s servers, but you get the point.


You can map a domain to a docker image and knative will spin that container up for you when needed, and kill it after a set time of inactivity.


The deployments are quite easy to setup as well, assuming you aren't doing anything fancy

```yaml
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: timestat
  namespace: timestat
spec:
  template:
    spec:
      containers:
        - image: ghcr.io/munhunger/timestat/kit:{{ .Values.version }}
          ports:
            - containerPort: 3000

Эта часть конфигурации — все, что нужно для получения контейнера узлов, доступного по адресу https://timestat.home.wunderdev.com/. , который запустится при необходимости и остановится в моем случае через 10 минут бездействия.

микрок8

Я планировал написать это некоторое время назад, но у меня возникли некоторые проблемы с обновлением моего кластера k8s для поддержки определенной версии knative с автоматической поддержкой TLS. И поскольку это был мой третий раз, когда мой кластер k8s блокировался во время обновления, я начал искать в другом месте, так как должен быть какой-то установщик k8s с разумными значениями по умолчанию. Этот поиск привел меня к моему новому любимому программному обеспечению, а именно microk8s.

Может быть, это не для производства, но для моей домашней установки это потрясающе.

Очень прост в установке и имеет довольно приличную поддержку плагинов (в том числе knative), так что вы можете быстро раскрутить узел с некоторыми крутыми контроллерами k8s и приступить к работе в течение часа!

Это ошеломляет, так как обычно мне требуется несколько часов, если не дней, чтобы настроить работающий кластер k8s (у меня все еще есть проблемы с сетевым уровнем).

Просто помните, если вы используете microk8s для создания доступа к вашему собственному сетевому шлюзу. Это вызвало у меня некоторую головную боль.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: kourier-ingress
  namespace: knative-serving
  annotations:
    cert-manager.io/cluster-issuer: lets-encrypt
spec:
  tls:
    - hosts:
        - '*.home.wunderdev.com'
      secretName: home-tls
  rules:
    - host: '*.home.wunderdev.com'
      http:
        paths:
          - backend:
              service:
                name: kourier
                port:
                  number: 80
            path: /
            pathType: Prefix

Без него nginx loadbalancer обслуживал все мои сетевые запросы, и, конечно же, у него не было концепции knative