por Mike Ton hace 7 años
989
Ver más
Encoded
VERIFY SIGNATURE
HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), ) secret base64 encoded
RhS5_R99IA0u_UffKr8xDh05Ob9Lb-kOBlmOWlspcc0
PAYLOAD:DATA
{ "sub": "1234567890", "name": "JWT made easy", "admin": true }
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpXVCBtYWRlIGVhc3kiLCJhZG1pbiI6dHJ1ZX0.
HEADER:ALGORITHM & TOKEN TYPE
{ "alg": "HS256", "typ": "JWT" }
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpXVCBtYWRlIGVhc3kiLCJhZG1pbiI6dHJ1ZX0.RhS5_R99IA0u_UffKr8xDh05Ob9Lb-kOBlmOWlspcc0
Information Exchange
Authentication
Logical Application
(Pod)
nginx
// One or more containers.
// Shared namespace
// One IP per pod
// That have dependencies with each other
(intro)
http://kubernetes.io/docs/user-guide/kubectl-cheatsheet/
// Kubernetes cheat sheet
kubectl get services
// List services
kubectl expose deployment nginx --port 80 --type LoadBalancer
// Expose nginx
kubectl get pods
// Get pods
kubectl run nginx --image=nginx:1.10.0
// Launch a single instance:
(setup)
Provision a Kubernetes Cluster with GKE using gcloud
gcloud container clusters create k0
Use project directory
cd craft/kubernetes
cd $GOPATH/src/github/com/udacity/ud615/craft/kubernetes
??? where is craft ???
pets vs. cattle
pods = anonymous instance (cattle)
vm/instance = single instance (pet)
diagram
(OSX)
(shell2)
docker run -e DISPLAY=192.168.59.3:0 jess/geary
# in another window
(shell1)
socat TCP-LISTEN:6000,reuseaddr,fork UNIX-CLIENT:\"$DISPLAY\"
open -a XQuartz
brew cask install xquartz
brew install socat
https://github.com/docker/docker/issues/8710
Public Vs Private Registries
Push Images
Create account on Dockerhub
Repeat for all images you created - monolith, auth and hello!
Login and use the docker push command
sudo docker push udacity/example-monolith:1.0.0
sudo docker login
https://hub.docker.com/register/
Add your own tag
For example (you can rename too!)
sudo docker tag monolith:1.0.0 udacity/example-monolith:1.0.0
sudo docker tag monolith:1.0.0
Docker tag command help
docker tag -h
See all images
(products)
Comparison Of 4 Registries
A write up comparing some of the different registries: http://rancher.com/comparing-four-hosted-docker-registries/
Google Cloud Registry
Finally, Google Cloud Registry (GCR) is a strong options for large enterprises. https://cloud.google.com/container-registry/docs/
Quay
Quay is another popular registry because of it’s rich automated workflow for building containers from github. https://quay.io/
Docker Hub
Docker Hub is the registry we’re using in this class. Go ahead and sign up for docker hub and create a repository so that you can follow along with the remaining lessons: https://hub.docker.com/
Commands To Run on the VM Instance
See the running containers
sudo docker ps -a
(Hello)
Build the hello app
CID3=$(sudo docker run -d hello:1.0.0)
sudo docker build -t hello:1.0.0 .
cd hello
(Auth)
Build the auth app
CID2=$(sudo docker run -d auth:1.0.0)
sudo docker build -t auth:1.0.0 .
cd auth
(MonoLith)
Test the container
curl $CIP
curl
Run the monolith container and get it's IP
(or???)
CIP=$(sudo docker inspect --format '{{ .NetworkSettings.IPAddress }}' ${CID})
CID=$(sudo docker run -d monolith:1.0.0)
sudo docker inspect
sudo docker run -d monolith:1.0.0
// -d : dry run?
// Nope -d = detached. Instance doesn't take over your shell
Create a container for the app
sudo docker images monolith:1.0.0
// List the monolith image
sudo docker build -t monolith:1.0.0 .
// Build the app container
cat monolith/Dockerfile
// Look at the Dockerfile
Build a static binary of the monolith app
go build --tags netgo --ldflags '-extldflags "-lm -lstdc++ -static"'
// Why did you have to build the binary with such an ugly command line?
// You have to explicitly make the binary static. This is really important in the Docker community right now because alpine has a different implementation of libc. So your go binary wouldn't of had the lib it needed if it wasn't static. You created a static binary so that your application could be self-contained.
go get -u
cd ud615/app/monolith
Get the app code
git clone https://github.com/udacity/ud615.git
cd $GOPATH/src/github.com/udacity
mkdir -p $GOPATH/src/github.com/udacity
Install Go
export GOPATH=~/go
export PATH=$PATH:/usr/local/go/bin
// "export" makes the change visible to new programs launched by bash
sudo tar -C /usr/local -xzf go1.6.2.linux-amd64.tar.gz
rm -rf /usr/local/bin/go
wget https://storage.googleapis.com/golang/go1.6.2.linux-amd64.tar.gz
Dockerfiles
ENTRYPOINT
["hello"]
// app to execute
ADD
hello
/usr/bin/hello
// Add files from our machine to location in container
MAINTAINER
Mike Ton
MikeTonEmail@gmail.com
FROM
alpine:3.1
// Which base to build Docker from
// Contains step by step instructions for creating Docker Images
// Remove the docker containers from the system
// or
sudo docker rm $(sudo docker ps -aq)
sudo docker rm
// Verify no more instances running
// Stop an instance
sudo docker stop
// Connect to the nginx using the internal IP
curl http://172.18.0.2
// Inspect the container
sudo docker inspect sharp_bartik
sudo docker inspect f86cf066c304
// List all running container processes
sudo docker ps -aq
// For use in shell scripts you might want to just get a list of container IDs (-a stands for all instances, not just running, and -q is for "quiet" - show just the numeric ID):
// Check how many instances are running
sudo ps aux | grep nginx
// Run another version of nginx
sudo docker run -d nginx:1.9.3
// Run a different version of nginx
sudo docker ps
// Check if it's up
sudo docker run -d nginx:1.10.0
// Run the first instance
// If your version of nginx from native package and Docker are different, you need to update the VM instance:
sudo dpkg -l | grep nginx
sudo docker pull nginx:1.10.0
sudo docker images
sudo apt-get install docker.io
// Their own port???
Modify nginx.conf
Need to specify a different port; 2 instances can't bind to the same port
Most OS allow one
curl http://127.0.0.1
sudo systemctl status nginx
start nginx
sudo systemctl start nginx
update packages and install nginx
nginx -v
sudo apt-get install nginx
sudo apt-get update
log into the VM instance
gcloud compute ssh ubuntu
launch a new VM instance
gcloud compute instances create ubuntu \ --image-project ubuntu-os-cloud \ --image ubuntu-1604-xenial-v20160420c
set compute/zone
gcloud config set compute/zone
gcloud compute zones list
// Note - Google Cloud shell is an ephemeral instance and will reset if you don't use it for more than 30 minutes. That is why you might have to set some configuration values again
Background
The contributors to this document have been directly involved in the development and deployment of hundreds of apps, and indirectly witnessed the development, operation, and scaling of hundreds of thousands of apps via our work on the Heroku platform.
This document synthesizes all of our experience and observations on a wide variety of software-as-a-service apps in the wild. It is a triangulation on ideal practices for app development, paying particular attention to the dynamics of the organic growth of an app over time, the dynamics of collaboration between developers working on the app’s codebase, and avoiding the cost of software erosion.
Our motivation is to raise awareness of some systemic problems we’ve seen in modern application development, to provide a shared vocabulary for discussing those problems, and to offer a set of broad conceptual solutions to those problems with accompanying terminology. The format is inspired by Martin Fowler’s books Patterns of Enterprise Application Architecture and Refactoring.
12 FACTORS
XII. Admin processes
Run admin/management tasks as one-off processes
XI. Logs
Treat logs as event streams
X. Dev/prod parity
Keep development, staging, and production as similar as possible
IX. Disposability
Maximize robustness with fast startup and graceful shutdown
VIII. Concurrency
Scale out via the process model
VII. Port binding
Export services via port binding
VI. Processes
Execute the app as one or more stateless processes
V. Build, release, run
Strictly separate build and run stages
IV. Backing services
Treat backing services as attached resources
III. Config
Store config in the environment
II. Dependencies
Explicitly declare and isolate dependencies
I. Codebase
One codebase tracked in revision control, many deploys
(Intro)
The twelve-factor methodology can be applied to apps written in any programming language, and which use any combination of backing services (database, queue, memory cache, etc).
In the modern era, software is commonly delivered as a service: called web apps, or software-as-a-service. The twelve-factor app is a methodology for building software-as-a-service apps that:
And can scale up without significant changes to tooling, architecture, or development practices.
Minimize divergence between development and production, enabling continuous deployment for maximum agility;
Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration;
Have a clean contract with the underlying operating system, offering maximum portability between execution environments;
Use declarative formats for setup automation, to minimize time and cost for new developers joining the project;
// Clean up
gcloud container clusters delete example-cluster
// list
gcloud container clusters list
// Run a container image
http://EXTERNAL-IP:8080
// View the app (replace EXTERNAL-IP with the external IP address you obtained in the previous step).
kubectl get service hello-node
// Copy the external IP address for the hello-node app
kubectl expose deployment hello-node --type="LoadBalancer"
// Expose the container. Note that the type="LoadBalancer option in kubectl requests that Google Cloud Platform provision a load balancer for your container.
kubectl run hello-node --image=gcr.io/google-samples/node-hello:1.0 --port=8080
// Run the container
gcloud container clusters create example-cluster
// Create a cluster (this step can take a few minutes to complete).
// Set gcloud defaults
gcloud config list
// To view your gcloud defaults at any time
gcloud config set compute/zone us-central1-b
app
MSA
(shell 3)
(interact with the auth and hello micro services)
curl -H "Authorization: Bearer $TOKEN" http://127.0.0.1:10082/secure
TOKEN=$(curl 127.0.0.1:10090/login -u user | jq -r '.token')
(auth service)
sudo ./bin/auth -http :10090 -health :10091
go build -o ./bin/auth ./auth
(hello service)
sudo ./bin/hello -http 0.0.0.0:10082
go build -o ./bin/hello ./hello
monolith
(shell 2)
(check out dependencies)
cat vendor/vendor.json
ls vendor/
//ls /vendor
(access the secure endpoint using the JWT)
curl -H "Authorization: Bearer $TOKEN" http://127.0.0.1:10081/secure
(login and assign the value of the JWT to a variable)
TOKEN=$(curl http://127.0.0.1:10081/login -u user | jq -r '.token')
// echo $TOKEN
(authenticate (password is password):)
curl http://127.0.0.1:10081/login -u user
// You can copy and paste the long token in to the next command manually, but copying long, wrapped lines in cloud shell is broken. To work around this, you can either copy the JWT token in pieces, or - more easily - by assigning the token to a shell variable as follows
// It prints out the token.
{"token":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJlbWFpbCI6InVzZXJAZXhhbXBsZS5jb20iLCJleHAiOjE0NzM5MDQyNTQsImlhdCI6MTQ3MzY0NTA1NCwiaXNzIjoiYXV0aC5zZXJ2aWNlIiwic3ViIjoidXNlciJ9.GAVtMr NeAYr2dqiYwF8ai0rqd-CIvZpuuOJPHAZYbDM"}
(test)
curl http://127.0.0.1:10081/secure
// Will fail. Need to authenticate
curl http://127.0.0.1:10081
// {"message":"Hello"}
//curl http://127.0.0.1:10080
(shell 1)
(run)
sudo ./bin/monolith -http :10080 -http :10081
(build)
// Optional - if you run into errors building your go binaries, you probably need to install the dependencies first by running:
$ go get -u
go build -o ./bin/monolith ./monolith
mkdir bin
cd $GOPATH/src/github.com/udacity/ud615/app
https://cloud.google.com/shell/docs/features
Built-in authorization for access to Cloud Platform Console projects and resources
Web preview functionality
Language support for Java, Go, Python, Node.js, PHP and Ruby
Pre-installed Google Cloud SDK and other tools
(temp)
You can install additional software packages on the virtual machine instance but the installation will not persist after the instance terminates unless you install the software in your $HOME directory.
(persistant)
tmux support
Cloud Shell supports the default tmux key bindings. For example, if you press Ctrl+b and then %, tmux splits the current session window into left and right panes, which can be useful for debugging.
Cloud Shell uses tmux by default, which allows it to improve persistence across browser tab sessions. For example, if you refresh the Cloud Platform Console in a tab or connect to your Cloud Shell from a different machine, the session state will not be lost.
Authorization
Cloud Shell provides built-in authorization for access to projects and resources hosted on Google Cloud Platform. You don't need to perform additional authorization steps to access platform resource using the Cloud SDK gcloud command-line tool.
Web Preview
Cloud Shell provides web preview functionality that allows you to run web applications on the virtual machine instance and preview them from the Cloud Platform Console. The web applications must listen for HTTP requests on ports within the permitted range 8080 to 8084. These ports are only available to the secure Cloud Shell proxy service, which restricts access over HTTPS to your user account only.
Language support
PHP
Ruby
Python
Go
Node.js
v0.12.2 and v4.1.2 (use nvm to switch versions)
Java
You can ignore any error messages about not being able to change the versions of some binaries. The version change will persist until the Cloud Shell virtual machine instance is terminated. If you want to permanently switch to Java 1.7, add the first command above to your .bashrc file.
JRE/JDK 1.7 and 1.8
sudo update-java-alternatives -s java-1.7.0-openjdk-amd64
// To change back to 1.7.0
sudo update-java-alternatives -s java-1.8.0-openjdk-amd64
// change the current Cloud Shell session to use version 1.8 of the JRE and JDK,
Additional tools
gRPC compiler
MySQL client
iPython
Docker
Source control tools
Mercurial
Git
Build and package tools
(others)
pip
nvm
Maven
Make
npm
Gradle
Text editors
Nano
Vim
Emacs
Google SDKs and tools
gsutil for Cloud Storage
Google Cloud SDK including the gcloud command
Google App Engine SDK
Linux utilities
Standard Debian system utilities
Linux shell interpreters
sh
bash
5 GB of persistent disk storage
Persistent disk storage
Cloud Shell provisions 5 GB of free persistent disk storage mounted as your $HOME directory on the virtual machine instance. This storage is on a per-user basis and is available across projects. Unlike the instance itself, this storage does not time out on inactivity. All files you store in your home directory, including installed software, scripts and user configuration files like .bashrc and .vimrc, persist between sessions. Your $HOME directory is private to you and cannot be accessed by other users.
Note: If you do not access Cloud Shell regularly, the $HOME directory persistent storage may be recycled. You will receive an email notification before this occurs. Starting a Cloud Shell session will prevent its removal.
Command-line access to the instance from a web browser
Command-line access
Cloud Shell provides command-line access to the virtual machine instance in a terminal window that opens in the Google Cloud Platform Console. You can open multiple shell connections to the same instance. The instance persists between sessions.
A temporary Compute Engine virtual machine instance
Virtual machine instance
When you start Cloud Shell, it provisions an f1-micro Google Compute Engine virtual machine running a Debian-based Linux operating system. Cloud Shell instances are provisioned on a per-user, per-session basis. The instance persists while your Cloud Shell session is active and terminates after an hour of inactivity.
// displays a list of installed Cloud SDK components and their versions:
