werf / website Goto Github PK

• Basic application
• Logging
• Serving assets
• Working with database
• Working with files
• Configuration and secrets

• Basic application
• Logging
• Serving assets
• Working with database
• Working with files
• Configuration and secrets

minikube version: v1.23.0
K8s version:  v1.22.1

MacOS Darwin 20.6.0 Darwin Kernel Version 20.6.0 RELEASE_X86_64 x86_64

The spring tutorial fails at the moment most likely due to the latest k8s version.

Running the command werf converge --repo <Docker Hub username>/werf-guide-app causes an error.

Error: helm upgrade have failed: unable to build kubernetes objects from release manifest: unable to recognize "": no matches for kind "Ingress" in version "networking.k8s.io/v1beta1"

According to this issue, the source of the issue seems to be the Ingress version specified in ingress.yaml file.

I changed the definition to this:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx
  name: werf-guide-app
spec:
  rules:
  - host: werf-guide-app
    http:
      paths:
      - path: /
        backend:
          serviceName: werf-guide-app
          servicePort: 8000

However, the issue still persists with the error:

Error: helm upgrade have failed: unable to build kubernetes objects from release manifest: error validating
"": error validating data: [ValidationError(Ingress.spec.rules[0].http.paths[0].backend): unknown field "ser
viceName" in io.k8s.api.networking.v1.IngressBackend, ValidationError(Ingress.spec.rules[0].http.paths[0].ba
ckend): unknown field "servicePort" in io.k8s.api.networking.v1.IngressBackend, ValidationError(Ingress.spec
.rules[0].http.paths[0]): missing required field "pathType" in io.k8s.api.networking.v1.HTTPIngressPath]

I believe the source of the error is coming from deployment.yaml but i am not an expert so wanted to create a new issue here

• Chapter "Working with files"
• Chapter "Managing app's configuration"
• #274
• #275
• #276
• #277

$ git grep werf_image
examples/springboot/230_assets/.helm/templates/deployment.yaml:        image: {{ tuple "node-assets" . | werf_image}}
ru.werf.io/guides/django/100_basic/30_deploy_registrysecret_remote.md:        image: {{ tuple "basicapp" . | werf_image }}
ru.werf.io/guides/golang/100_basic/30_deploy_registrysecret_remote.md:        image: {{ tuple "basicapp" . | werf_image }}
ru.werf.io/guides/java_springboot/200_real_apps/30_assets.md:        image: {{ tuple "node-assets" . | werf_image}}
ru.werf.io/guides/nodejs/100_basic/30_deploy_registrysecret_remote.md:        image: {{ tuple "basicapp" . | werf_image }}
ru.werf.io/guides/nodejs/200_real_apps/30_assets.md:        image: {{ tuple "basicapp" . | werf_image}}
ru.werf.io/guides/nodejs/200_real_apps/30_assets.md:        image: {{ tuple "node-assets" . | werf_image}}
ru.werf.io/guides/nodejs/200_real_apps/50_files.md:        image: {{ tuple "basicapp" . | werf_image}}
ru.werf.io/guides/nodejs/200_real_apps/50_files.md:        image: {{ tuple "basicapp" . | werf_image}}
ru.werf.io/guides/nodejs/200_real_apps/60_email.md:        image: {{ tuple "basicapp" . | werf_image}}
ru.werf.io/guides/nodejs/200_real_apps/60_email.md:        image: {{ tuple "basicapp" . | werf_image}}
ru.werf.io/guides/nodejs/200_real_apps/80_database.md:        image: {{ tuple "basicapp" . | werf_image }}
ru.werf.io/guides/nodejs/200_real_apps/80_database.md:          image: {{ tuple "basicapp" . | werf_image }}
ru.werf.io/guides/rails/100_basic/30_deploy_registrysecret_remote.md:        image: {{ tuple "basicapp" . | werf_image }}
werf.io/guides/java_springboot/200_real_apps/30_assets.md:        image: {{ tuple "basicapp" . | werf_image}}
werf.io/guides/java_springboot/200_real_apps/30_assets.md:        image: {{ tuple "node-assets" . | werf_image}}
werf.io/guides/nodejs/100_basic/30_deploy_registrysecret_remote.md:        image: {{ tuple "basicapp" . | werf_image }}
werf.io/guides/nodejs/200_real_apps/30_assets.md:        image: {{ tuple "basicapp" . | werf_image}}
werf.io/guides/nodejs/200_real_apps/30_assets.md:        image: {{ tuple "node-assets" . | werf_image}}
werf.io/guides/nodejs/200_real_apps/50_files.md:        image: {{ tuple "basicapp" . | werf_image}}
werf.io/guides/nodejs/200_real_apps/50_files.md:        image: {{ tuple "basicapp" . | werf_image}}
werf.io/guides/nodejs/200_real_apps/60_email.md:        image: {{ tuple "basicapp" . | werf_image}}
werf.io/guides/nodejs/200_real_apps/60_email.md:        image: {{ tuple "basicapp" . | werf_image}}
werf.io/guides/nodejs/200_real_apps/80_database.md:        image: {{ tuple "basicapp" . | werf_image }}
werf.io/guides/nodejs/200_real_apps/80_database.md:          image: {{ tuple "basicapp" . | werf_image }}

Use .Values.werf.image.NAME instead of werf_image template.

Now the domain (werf-guide-app) is the same as the Kubernetes resource names and sometimes this confuses the user. For example, here:

apk add curl  # Installing curl in the container.
curl http://werf-guide-app:8000/ping  # curl to one of the pods of our application using the service.

• Life cycle
• High availability
• Resource management

I use werf for ci and it's really good for that, but when I needed to install it on few Windows machines it took a little longer than I expected. Can't we use a different installation method for werf?
As for me, installing trdl, updating $PATH and $PROFILE to install 1 binary file is too complicated and takes too much time.

It will be more convenient if there are next and prev. links on a page

• Правки по форме (от наиболее приоритетного к менее приоритетному):
  • [Сергей] Ссылок на мастер быть не должно. Переделать на {% include snippetcut_example ... для инклюда файлов целиком/инклюда больших сниппетов. И на {% include_file ... для маленьких сниппетов в несколько строчек. syntax=... параметр обязательно указывать. Не забыть прилегающий текст проверить, ему могут потребоваться правки.
  • [Сергей] Многие файлы не нужно инклюдить целиком, только релевантные кусочки.
    Например, целиком Gemfile показывать в месте, где мы на mysql переключаемся и добавляем mysql-гем, явно лишннее. Надо использовать snippet= параметр для snippetcut_example или include_file. Как объявить сниппет в самом файле описано здесь: https://github.com/flant/jekyll_include_plugin/#usage
  • [Сергей] Все инструкции должны быть рабочими.
    Например, URL:PORT уже пора поменять на чето реальное в curl "http://URL:PORT/api/labels/".
  • [Сергей] У каждой команды должен быть вывод.
    Второстепенный/слишком большой вывод можно засовывать под спойлеры???
  • [Сергей] Вызов команд и их вывод должны быть разделены на отдельные код-блоки, если они ещё где-то в одном.
  • [Сергей] В целом всё должно быть однообразно между разными статьями.
    Тот же стиль, так же пишутся термины (Ingress или ингресс? mysql/MySQL? "Ответ будет примерно таким" или "результат в случае успешного выполнения"?). Однообразны должны быть не только формулировки, но и структура статей.
• Подготовка окружения
  • После того, как запущен тунель и домен добавлен в hosts, хорошо бы проверить ответ 404 от nginx.
  • [Илья] Добавить шаги, которые необходимо выполнять при перезагрузке системы. Упомянуть в header.
  • Настройка Container Registry: добавить опцию --docker-server и опционально добавить ссылку на https://jamesdefabia.github.io/docs/user-guide/kubectl/kubectl_create_secret_docker-registry/ .
• [Илья] Добавить во все статьи header со ссылкой на раздел-подготовку.
• [Илья] Автодобавлять page header в /layout/... ? Переименовать page header в chapter header?
• [Илья] Добавить во все статьи header с инструкциями как подготовить состояние гита для данной статьи.

# примерная шапка:
test -d ~/werf-guides-rails/werf-guides || git clone https://github.com/werf/werf-guides ~/werf-guides-rails/werf-guides
cd ~/werf-guides-rails/
rm -rf 100_db_init_and_migrations
cp -rf werf-guides/examples/rails/019_fixup_consistency 100_db_init_and_migrations
cd 100_db_init_and_migrations
git init
git add .
git commit -m "initial"

cp -r --no-target-directory ../werf-guides/examples/rails/100_db_init_and_migrations .
git add .
git diff --staged --stat

# примерный промежуточный хедер для стадий внутри главы
git commit -m '2'
cp -rT examples/rails/200_real_apps/logging-stage2 .
git add .
git diff --stat --staged

• [Илья] Перенести создание секрета из раздела-подготовки в сниппет с подготовкой состояния гита (сразу после).
• [Илья] Дисклеймер сверху о том, что эти примеры нельзя копипастить как есть
• Убрать везде git init --separate-git-repo, сделать явные cp / rm.
• werf converge --repo <имя пользователя Docker Hub>/werf-guided-rails
• Если занят 80 порт, то пользователь об этом никак не узнает (windows only).

https://werf.io/guides.html

Now the chapter doesn't work with the existing header. Header supposes that just after it we are going to explain the changes we are going to do in this chapter, applying the changes afterwards. But this chapter requires you to have the previous chapter repo state, then do something in the cluster manually, then deploy the previous chapter state again, and only after that we are actually making any changes to the repo.

It might be easier to change the chapter a bit to fit the usual structure instead of overcomplicating logic in the header (it is complex enough already).

It would be nice to have at least a quick guide on how to get it running.

Reproduction:

1. Go to: Разворачиваем приложение на Node.js в среде Kubernetes
2. Click on btn Показать, что уже готово.
3. Nothing happens.

In Code

Removal of {% asset details.js %} resulted in:

This affects all pages.
https://github.com/werf/werf-guides/blob/c32cfe34bceabe9c6537755219146cb32f08c336/ru.werf.io/guides/_layouts/wip.html#L18

The changes that led to this: 64d0738#r49666757

Based on checklist from here: werf/werf#4000

samarpan rai has kindly informed us that our "First steps" still use networking.k8s.io/v1beta1 API version Ingress resources (this manifest). That doesn't work in newer Kubernetes versions. We need to fix it in a consistent way (keeping backward compatibility for older K8s).

• Basic application
• Logging
• Serving assets
• Working with database
• Working with files
• Configuration and secrets

Starting from /guides/django/200_real_apps/040_db.html, guide raise errors if used with recent versions of images.
At first, mysqlclient for pip just doesn't build. Here they write that mariadb-dev should be added to packages. With this addition it compiles successfully.

But this is not enough. at the stage of starting the migration job, we get
django.db.utils.NotSupportedError: MySQL 8 or later is required (found 5.7.42).
so the db image version needs to be raised from 5.7 to 8.0 (in the topic about secrets, this has already been done)

Maybe this, of course, is deliberately left like that? :)

• Make sidebar menu floating.
• Collapse inactive sidebar sections.
• Add TOC.
• Add "Go to the prev/next chapter" link to the end.
• Change button text "Star it if you like it!" to "Leave a star if you like it!".
• Move the button "Have a question? Ask us!" above the sidebar menu.
• (?) Add the button "Prepare/fix the environment" linked to Preparing the environment chapter under the button "Have a question? Ask us!".
• Update the "Preparing the environment" part at the beginning of a chapter.

Any unexpected value passed to any GET parameter on the installation page breaks the page, i.e. https://werf.io/installation.html?method=trdl

We should fall back to some default GET parameter values if we get unexpected/invalid values.

• Basic application
• Logging
• Serving assets
• Working with database
• Working with files
• Configuration and secrets

example https://habr.com/ru/company/habr/blog/442208/

Working through the tutorial https://werf.io/guides/nodejs/100_basic/10_build.html one gets

Error: --stages-storage=ADDRESS param required

from werf build and werf run --docker-options="--rm -p 3000:3000" -- node /app/app.js

By searching through the project files it seems that the tutorial should instruct users to:
werf build --stages-storage :local
and

werf run --docker-options="--rm -p 3000:3000" --stages-storage=:local -- node /app/app.js

• Add an introductory text that briefly describes why we use release channels and contains a link to the "Release channels" page.
• To the right of all the buttons, add a block of text informing about the ability to download a certain version via a link in the release message.