Happywzy

enjoy coding...

0%

发表于 分类于

nginx 配置

默认情况下 nginx 已经安装了 ngx_http_auth_basic_module 模块.

server {
    #监听端口号
    listen       8081;
    auth_basic "config Auth";
    #用户密码文件地址
    auth_basic_user_file    /etc/nginx/passwd.db;
    location / {
    　　 #代理地址
        proxy_pass http://192.168.31.1:8080/;
        proxy_redirect default;
    }
}

auth_basic_user_file 和 auth_basic 也可以放到 server -> location 内.

其中 auth_basic_user_file 可以使用 htpasswd 在linux生成.

htpasswd 使用

# 安装
yum -y install httpd-tools
# 生成
htpasswd -bc /etc/nginx/passwd.db admin Mima@123

发表于 分类于 ，

grafana

grafana 支持集成 ldap ，grafana 镜像默认在 /etc/grafana/ 目录下有个 ldap.toml 文件用于配置 ldap .

grafana.ini

首先需要在 grafana.ini 主配置中开启 ldap

[auth.ldap]
enabled = true
config_file = /etc/grafana/ldap.toml
allow_sign_up = true	
# LDAP backround sync (Enterprise only)
# At 1 am every day
sync_cron = "0 0 1 * * *"
active_sync_enabled = true

更改配置后重启生效.

ldap.toml

# To troubleshoot and get more log info enable ldap debug logging in grafana.ini
# [log]
# filters = ldap:debug

[[servers]]
# Ldap server host (specify multiple hosts space separated)
host = "172.168.0.2"
# Default port is 389 or 636 if use_ssl = true
port = 389
# Set to true if ldap server supports TLS
use_ssl = false
# Set to true if connect ldap server with STARTTLS pattern (create connection in insecure, then upgrade to secure connection with TLS)
start_tls = false
# set to true if you want to skip ssl cert validation
ssl_skip_verify = false
# set to the path to your root CA certificate or leave unset to use system defaults
# root_ca_cert = "/path/to/certificate.crt"
# Authentication against LDAP servers requiring client certificates
# client_cert = "/path/to/client.crt"
# client_key = "/path/to/client.key"

# Search user bind dn
bind_dn = "cn=admin,dc=xxxx,dc=xxxxx"
# Search user bind password
# If the password contains # or ; you have to wrap it with triple quotes. Ex """#password;"""
bind_password = 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxx'

# User search filter, for example "(cn=%s)" or "(sAMAccountName=%s)" or "(uid=%s)"
search_filter = "(cn=%s)"

# An array of base dns to search through
search_base_dns = ["ou=xxxx,dc=xxxxx,dc=xxxxx"]

## For Posix or LDAP setups that does not support member_of attribute you can define the below settings
## Please check grafana LDAP docs for examples
# group_search_filter = "(&(objectClass=posixGroup)(memberUid=%s))"
# group_search_base_dns = ["ou=groups,dc=grafana,dc=org"]
# group_search_filter_user_attribute = "uid"

# Specify names of the ldap attributes your ldap uses
[servers.attributes]
name = "displayName"
# surname = "sn"
username = "cn"
member_of = "memberOf"
email =  "email"

# Map ldap groups to grafana org roles
# [[servers.group_mappings]]
# group_dn = "*"
# org_role = "Admin"
# To make user an instance admin  (Grafana Admin) uncomment line below
# grafana_admin = true
# The Grafana organization database id, optional, if left out the default org (id 1) will be used
# org_id = 1

# [[servers.group_mappings]]
# group_dn = "ou=xxxxx,dc=xxxxxx,dc=xxxxxx"
# org_role = "Editor"

# [[servers.group_mappings]]
# If you want to match all (or no ldap groups) then you can use wildcard
# group_dn = "*"
# org_role = "Viewer"

发表于 分类于 ，

前言

通过 helm 部署的 Loki 默认都是采用一个副本，如果想部署集群方案直接将 Loki 副本数改成 3 或者其它数是不行的，网上集群相关的文档也比较少，不过在 Loki 官方仓库 production 目录下有相关的配置样例，具体参考 production。

Loki组件

loki

  • Distributor（分配器）
    Distributor主要负责分发从客户端上报的日志, 在进行完日志的校验之后便会分发给ingester处理. Distributor使用了一致性哈希以及一个可以配置的副本数来决定不同的日志流的后端ingester. 哈希环信息的存储使用了Consul. Ingester会根据自身的状态注册在哈希环上来标识自身可提供服务的状态. Distributor会使用注册租户id和标签集时作为哈希的输入, 计算出对应的哈希环位置, 并找到对应的ingester.
  • Ingester（采集器）
    Ingester是loki中比较核心的服务, 该服务将从Distributor发送来的日志进行转储到后端存储, 并给Querier提供仍在内存中未写盘的数据查询功能.
    Ingester注册在哈希环上的状态有PENDING, JOINING, ACTIVE, LEAVING, UNHEALTHY, 除了ACTIVE状态外, 其余状态都只会提供部分服务。
    在存储到真正的存储前, 日志流只有按顺序收到才会被处理, Ingester会按照标签的组合set构建若干压缩过的chunks, 间隔一段时间将chunks作为整体刷写到后端存储. 刷进后端存储的chunks被标记为只读.
  • Querier frontend
    该服务是一个可选组件，在一组查询器前面，来负责在它们之间公平地调度请求，尽可能地并行化它们并缓存请求。
  • Querier（查询器）
    Querier则是用来提供查询服务, 他使用了LogQL, 一种类似于PromQL的语言作为用户界面. Querier会查询已经写入后端存储的chunks以及仍在ingester内存中的数据, 根据label查找数据后, 再遍历数据查找到满足条件的日志
  • Chunk（块）存储
    Chunk Store是Loki的后端存储框架, 可以支持多种存储方式, 存储分为两部分:索引的存储（Index）和日志数据存储.
    loki

Loki集群方案

loki

  • loki 核心服务 distributor、ingester、querier 没有分离，而是启动在一个实例当中；
  • 是直接用 memberlist 在内存中维护集群状态；
  • 使用 boltdb-shipper 替代其他日志索引方案

Loki集群配置

config:
  ingester:
    lifecycler:
      ring:
        kvstore:
        # store 支持 consul, etcd, inmemory, memberlist
          store: memberlist
        # 设置副本数
        replication_factor: 1
  memberlist:
    # 加入集群的节点地址列表
    join_members: ["loki-1.loki-headless.loki", "loki-2.loki-headless.loki", "loki-0.loki-headless.loki"]

Loki helm安装

Promtail 配置注意事项

  • vim charts/promtail/values.yaml
# Extra volumes to scrape logs from
volumes:
  name: docker
  hostPath:
    # 修改为docker的实际路径
    path: /home/docker/containers
#  ...
volumeMounts:
  name: docker
  # 修改为docker的实际路径
  mountPath: /home/docker/containers
  readOnly: true

参考文档

  • 参考文档：1

发表于 分类于

常用命令

# 添加仓库, 如
helm repo add loki https://grafana.github.io/loki/charts
# 更新仓库
helm repo update
# 安装服务并设置自定义配置
helm install loki --namespace=loki loki/loki-stack --set grafana.enabled=true
# 下载chart到本地
helm pull loki/loki-stack
# 使用本地chart安装服务
helm install loki --namespace=loki  .
helm install opentelemetry-collector  .
helm install tempo ./tempo/  --values ./tempo/values.yaml -nloki
  • helm install 等价于 helm upgrade --install
  • 如果安装前没有创建 namespace 可以添加命令 --create-namespace 自动创建

发表于 分类于

Ingress-Nginx Annotation 简介

KubeSphere 基于 Nginx Ingress Controller 实现了项目的网关，作为项目对外的流量入口和项目中各个服务的反向代理。而 Ingress-Nginx 支持配置 Ingress Annotations 来实现不同场景下的灰度发布和测试，可以满足金丝雀发布、蓝绿部署与 A/B 测试等业务场景。

Nginx Annotations 支持以下 5 种 Canary 规则：

  • nginx.ingress.kubernetes.io/canary-by-header：基于 Request Header 的流量切分，适用于灰度发布以及 A/B 测试。当 Request Header 设置为 always 时，请求将会被一直发送到 Canary 版本；当 Request Header 设置为 never 时，请求不会被发送到 Canary 入口；对于任何其他 Header 值，将忽略 Header，并通过优先级将请求与其他金丝雀规则进行优先级的比较。
  • nginx.ingress.kubernetes.io/canary-by-header-value：要匹配的 Request Header 的值，用于通知 Ingress 将请求路由到 Canary Ingress 中指定的服务。当 Request Header 设置为此值时，它将被路由到 Canary 入口。该规则允许用户自定义 Request Header 的值，必须与上一个 annotation (即：canary-by-header) 一起使用。
  • nginx.ingress.kubernetes.io/canary-by-header-pattern：要匹配的 Request Header 值的 PCRE 正则表达式，作用同上面的 canary-by-header-value 一样，当 Request Header 设置的值满足该正则表达式时，它将被路由到 Canary 入口，必须与 canary-by-header 一起使用。
  • nginx.ingress.kubernetes.io/canary-weight：基于服务权重的流量切分，适用于蓝绿部署，权重范围 0 - 100按百分比将请求路由到 Canary Ingress 中指定的服务。权重为 0 意味着该金丝雀规则不会向 Canary 入口的服务发送任何请求，权重为 100 意味着所有请求都将被发送到 Canary 入口。
  • nginx.ingress.kubernetes.io/canary-by-cookie：基于 cookie 的流量切分，适用于灰度发布与 A/B 测试。用于通知 Ingress 将请求路由到Canary Ingress中指定的服务的 cookie。当 cookie 值设置为 always 时，它将被路由到 Canary 入口；当 cookie 值设置为 never 时，请求不会被发送到 Canary 入口；对于任何其他值，将忽略 cookie 并将请求与其他金丝雀规则进行优先级的比较。

注意：金丝雀规则按优先顺序进行如下排序：

canary-by-header - > canary-by-cookie - > canary-weight

使用

  • 创建两个不同版本的service及ingress
  • 两个ingress使用相关的域名，但是后端服务使用不同版本的
  • canary版本的ingress增加nginx.ingress.kubernetes.io/canary: "true" 启用 Canary
  • 其余策略参考nginx annotation