If this codebase is production, handles money, or touches sensitive data: treat this audit loop as a high-risk operation. Run with least privilege, avoid exporting long-lived credentials in your shell, and keep the agent in read-only mode.
| import NextAuth, { type NextAuthOptions } from "next-auth"; | |
| import { JWT } from "next-auth/jwt"; | |
| import * as jwt from "jose"; | |
| export const authOptions: NextAuthOptions = { | |
| // the rest is just like in tutorials. Session, callbacks etc. | |
| jwt: { | |
| encode: async ({ secret, token }) => { | |
| if (!token) { | |
| console.warn("encode: No token provided"); |
| # Create a k8s cluster | |
| git clone https://github.com/vfarcic/devops-toolkit-crossplane | |
| cd devops-toolkit-crossplane | |
| helm repo add crossplane-stable \ | |
| https://charts.crossplane.io/stable | |
| helm repo update |
| version: '3' | |
| volumes: | |
| wordpress: | |
| db: | |
| services: | |
| wordpress: | |
| image: wordpress:5.7.1-fpm-alpine | |
| container_name: ${WP_CONTAINER_NAME} |
| Aspect or Feature | kubernetes/ingress-nginx | nginxinc/kubernetes-ingress with NGINX | nginxinc/kubernetes-ingress with NGINX Plus |
|---|---|---|---|
| Fundamental | |||
| Authors | Kubernetes community | NGINX Inc and community | NGINX Inc and community |
| NGINX version | Custom NGINX build that includes several third-party modules | NGINX official mainline build | NGINX Plus |
| Commercial support | N/A | N/A | Included |
| Implemented in | Go/Lua (while Nginx is written in C) | Go/Python | Go/Python |
| Load balancing configuration via the Ingress resource |
Registering Rancher managed clusters in Argo CD doesn't work out of the box unless the Authorized Cluster Endpoint is used. Many users will prefer an integration of Argo CD via the central Rancher authentication proxy (which shares the network endpoint of the Rancher API/GUI). So let's find out why registering clusters via Rancher auth proxy fails and how to make it work.
Hint: If you are just looking for the solution scroll to the bottom of this page.
The Mainflux domain model is based around 3 entities: users, things and channels
user represents the real (human) user of the system
things represents devices and applications connected to Mainflux. There are two types of "things" supported at the moment: device and app. Device is used to represent any physical device connected to the platform. App represents any 3rd party service that uses the platform for message exchange with things.
channel represents a communication channel and serves as message topic that can be consumed by things connected to it
| #!/bin/bash | |
| # Usage: ./get_kubeconfig_custom_cluster_rancher2.sh cluster_name | |
| # Needs to be run on the server running `rancher/rancher` container | |
| # Check if jq exists | |
| command -v jq >/dev/null 2>&1 || { echo "jq is not installed. Exiting." >&2; exit 1; } | |
| # Check if clustername is given | |
| if [ -z "$1" ]; then | |
| echo "Usage: $0 [clustername]" |
| #cloud-config | |
| # do not reisze, we are going to do that our self. Because the resizefs will run before the disk setup | |
| resize_rootfs: false | |
| # setup disk, overwriting our live partition scheme | |
| # results in a 4G/16GB split on a cx11 | |
| # overwrite needs to be true because we are going to change the layout of an existing drive | |
| disk_setup: | |
| /dev/sda: |