<Additional information about your API call. Try to use verbs that match both request type (fetching vs modifying) and plurality (one vs multiple).>
-
URL
<The URL Structure (path only, no root url)>
-
Method:
A running example of the code from:
Small refactorings made to original code:
| -- show running queries (pre 9.2) | |
| SELECT procpid, age(clock_timestamp(), query_start), usename, current_query | |
| FROM pg_stat_activity | |
| WHERE current_query != '<IDLE>' AND current_query NOT ILIKE '%pg_stat_activity%' | |
| ORDER BY query_start desc; | |
| -- show running queries (9.2) | |
| SELECT pid, age(clock_timestamp(), query_start), usename, query | |
| FROM pg_stat_activity | |
| WHERE query != '<IDLE>' AND query NOT ILIKE '%pg_stat_activity%' |
| # -------------------------------------------------------------------- | |
| # Copyright (c) 2019 LINKIT, The Netherlands. All Rights Reserved. | |
| # Author(s): Anthony Potappel | |
| # | |
| # This software may be modified and distributed under the terms of the | |
| # MIT license. See the LICENSE file for details. | |
| # -------------------------------------------------------------------- | |
| # If you see pwd_unknown showing up, this is why. Re-calibrate your system. | |
| PWD ?= pwd_unknown |
| -- Create a group with read-only access | |
| CREATE ROLE readonly; | |
| -- Grant access on public sheme to existing tables | |
| GRANT USAGE ON SCHEMA public TO readonly; | |
| ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO readonly; -- grant access to future tables | |
| -- Grant access to specific database, repeat code below for each database | |
| GRANT CONNECT ON DATABASE db_name to readonly; | |
| ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT ALL ON TABLES TO readonly; -- grant access to future tables |
| #!/bin/bash | |
| letsencrypt renew -m [EMAIL] --agree-tos | |
| for file in /etc/ipsec.d/private/*; | |
| do | |
| CERTDOMAIN=`basename $file .pem`; | |
| diff -q /etc/ipsec.d/private/${CERTDOMAIN}.pem /etc/letsencrypt/live/${CERTDOMAIN}/privkey.pem || cp -L /etc/letsencrypt/live/${CERTDOMAIN}/privkey.pem /etc/ipsec.d/private/${CERTDOMAIN}.pem | |
| diff -q /etc/letsencrypt/live/${CERTDOMAIN}/cert.pem /etc/ipsec.d/certs/${CERTDOMAIN}.pem || cp -L /etc/letsencrypt/live/${CERTDOMAIN}/cert.pem /etc/ipsec.d/certs/${CERTDOMAIN}.pem | |
| done | |
| ipsec restart |
| #!/usr/bin/env bash | |
| export TAG= | |
| export COMMIT_SHA= | |
| export GITHUB_TOKEN= | |
| export GITHUB_USER= | |
| export GITHUB_REPO= | |
| export GO_BINARY_NAME= | |
| set -u -e -o pipefail |
Kubernetes is great! It helps many engineering teams to realize the dream of SOA (Service Oriented Architecture). For the longest time, we build our applications around the concept of monolith mindset, which is essentially having a large computational instance running all services provided in an application. Things like account management, billing, report generation are all running from a shared resource. This worked pretty well until SOA came along and promised us a much brighter future. By breaking down applications to smaller components, and having them to talk to each other using REST or gRPC. We hope expect things will only get better from there but only to realize a new set of challenges awaits. How about cross services communication? How about observability between microservices such as logging or tracing? This post demonstrates how to set up OpenTracing inside a Kubernetes cluster that enables end-to-end tracing between serv