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 |
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} |
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: |
#cloud-config | |
# vim: syntax=yaml | |
# | |
# The current version of cloud-init in the Hypriot rpi-64 is 0.7.9 | |
# When dealing with cloud-init, it is SUPER important to know the version | |
# I have wasted many hours creating servers to find out the module I was trying to use wasn't in the cloud-init version I had | |
# Documentation: http://cloudinit.readthedocs.io/en/0.7.9/index.html | |
# Set your hostname here, the manage_etc_hosts will update the hosts file entries as well |