Архив метки: Devops

Сравнение DevOps и Agile — Какой подход лучше выбрать для вашего проекта

Сравнение DevOps и Agile — Какой подход лучше выбрать для вашего проекта

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

🚀 13 Docker‑трюков, которые стоит знать каждому программисту

Docker Multi-stage builds

1. Multi-stage builds

Позволяет собирать образы в несколько этапов, оставляя в финальном образе только нужное:

FROM golang:1.22 AS builder
WORKDIR /app
COPY . .
RUN go build -o myapp .

FROM alpine:3.20
COPY —from=builder /app/myapp /usr/local/bin/
ENTRYPOINT [«myapp»]

🔹 Зачем: уменьшаем размер финального образа и избавляемся от лишнего ПО (компиляторов, зависимостей).
🔹 Когда: при сборке любого backend-приложения, особенно Go, Rust, Java. Читать

Что такое DevOps и как стать таким специалистом?

Что такое DevOps?

DevOps — это подход к разработке программного обеспечения, который объединяет разработчиков и операционных специалистов для более эффективной работы. Он основан на сотрудничестве, автоматизации и непрерывной интеграции и развертывании программного обеспечения. Читать

Метрики Qrator (Qrator Exporter)

В очередной раз пришлось настраивать сбор метрик с Qrator, прошлая моя заметка на этот счет жила в виде Issue в репозитории StupidScience/qrator-exporter (в проекте используются deprecated-методы), но там она пропала, поэтому опишу здесь, чтобы уж точно не потерялось.

Источник qratorlabs.medium.com

 

Сбор данных будет осуществляться через telegraf и, с помощью него же, отдаваться в виде метрик формата Prometheus.

Читать

Проксирование внешнего веб-сайта с помощью Nginx Ingress

Представьте, что у вас есть веб-сервер, работающий вне вашего кластера Kubernetes, который вы хотите интегрировать в свой контроллер ingress. Существует несколько причин, по которым вы можете захотеть это сделать:




  • Внешний веб-сервер разработан не таким образом, чтобы вы могли (легко) запустить его в контейнере вашего кластера.



  • Возможно, внешний веб-сервер запущен в другом центре обработки данных, чем ваш кластер Kubernetes.



  • Вы хотите воспользоваться преимуществами автоматической настройки HTTPS вашего контроллера Nginx Ingress.




Оказывается, на самом деле это довольно просто настроить.




В этом примере мы предполагаем, что внешний веб-сайт размещен на IP-адресе 10.20.30.40 и прослушивается через порт 8080. Обратите внимание, что для этого примера мы предполагаем, что порт 8080 обслуживает незашифрованный простой HTTP.




Также убедитесь, что вы правильно настроили свой брандмауэр и ограничили IP-адрес, по которому этот веб-сервер принимает подключения. Вы же не хотите открывать незашифрованный порт 8080 для всего мира.




Прежде всего, вам необходимо создать сервис с конечной точкой:




service.yaml




apiVersion: v1
kind: Service
metadata:
  name: <my-external-service>
spec:
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 8080
  clusterIP: None
  type: ClusterIP
---
apiVersion: v1
kind: Endpoints
metadata:
  name: <my-external-service>
subsets:
- addresses:
  - ip: 10.20.30.40
  ports:
  - name: http
    port: 8080
    protocol: TCP




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




Загрузка его в кластер выполняется следующим образом:




$ kubectl apply -f service.yaml




Для завершения настройки мы добавляем сервис в определение ingress точно так же, как мы бы поступили с обычным сервисом:




ingress.yaml




apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress
  annotations:
    nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "3600"
    kubernetes.io/ingress.class: nginx
    certmanager.k8s.io/cluster-issuer: letsencrypt-prod
spec:
  tls:
  - hosts:
    - <my-domain-name.com>
    secretName: letsencrypt-prod
  rules:
  - host: <my-domain-name.com>
    http:
      paths:
      - backend:
          serviceName: <my-external-service>
          servicePort: 80




Примените это также, и все готово.




$ kubectl apply -f ingress.yaml




Если вы сейчас перейдете на https://my-domain-name.com, должно появиться правильное содержимое.




Источник: https://www.yellowduck.be/posts/k8s-proxy-an-external-site



2023-06-26T23:11:25
DevOps