This article is an overview of IAM implementations, focused on multi-tenancy deployments.
- IAM User - IAM access account. IAM Group - A grouping of IAM Users.
Blockchain reading notes
Rocket Pool
Designing Event-Driven Systems book by Ben Stopford contains a lot of useful links to papers, books, documentation and definitions related to event driven design and Kafka. I just extracted them as reference for the future and added some groups to show them better.
You can read the book for free
Vertical decomposition. Creating cohesive services
One of the biggest misconceptions about services is that a service is an independent deployable unit, i.e., service equals process. With this view, we are defining services according to how components are physically deployed. In our example, since it’s clear that the backend admin runs in its own process/container, we consider it to be a service.
But this definition of a service is wrong. Rather you need to define your services in terms of business capabilities. The deployment aspect of the system doesn’t have to be correlated to how the system has been divided into logical services. For example, a single service might run in different components/processes, and a single component might contain parts of multiple services. Once you start thinking of services in terms of business capabilities rather than deployment units, a whole world of options open.
What are the Admin UI
This focuses on generating the certificates for loading local virtual hosts hosted on your computer, for development only.
Do not use self-signed certificates in production ! For online certificates, use Let's Encrypt instead (tutorial).
#!/bin/sh | |
# OUTDATED: please refer to the link below for the latest version: | |
# https://github.com/rancherlabs/support-tools/blob/master/extended-rancher-2-cleanup/extended-cleanup-rancher2.sh | |
docker rm -f $(docker ps -qa) | |
docker volume rm $(docker volume ls -q) | |
cleanupdirs="/var/lib/etcd /etc/kubernetes /etc/cni /opt/cni /var/lib/cni /var/run/calico /opt/rke" | |
for dir in $cleanupdirs; do | |
echo "Removing $dir" | |
rm -rf $dir | |
done |
# Alert when a login event is detected for user "admin" never before seen IP | |
# In this example, "login" logs contain which user has logged in from what IP | |
# (Optional) | |
# Elasticsearch host | |
es_host: localhost | |
# (Optional) | |
# Elasticsearch port | |
es_port: 9200 |
This guide was written because I don't particularly enjoy deploying Phoenix (or Elixir for that matter) applications. It's not easy. Primarily, I don't have a lot of money to spend on a nice, fancy VPS so compiling my Phoenix apps on my VPS often isn't an option. For that, we have Distillery releases. However, that requires me to either have a separate server for staging to use as a build server, or to keep a particular version of Erlang installed on my VPS, neither of which sound like great options to me and they all have the possibilities of version mismatches with ERTS. In addition to all this, theres a whole lot of configuration which needs to be done to setup a Phoenix app for deployment, and it's hard to remember.
For that reason, I wanted to use Docker so that all of my deployments would be automated and reproducable. In addition, Docker would allow me to have reproducable builds for my releases. I could build my releases on any machine that I wanted in a contai
type product = { | |
category: string, | |
price: string, | |
stocked: bool, | |
name: string | |
}; | |
type products = list(product); | |
let products = [ |