https://lucid.app/lucidchart/647bb2fa-3820-458a-bd2c-3f0f8520add7/edit?page=-8ZpAu3F4v8S#
Think of uwsgi as processes that take incoming HTTP requests, run special python code (django views), and then return HTTP responses. Here is a great video that explains wsgi
| ''' | |
| When you're developing an Endpoint with Django Rest Framework, in some situations you'll want to re-use it for generating example data, make tests (e.g. in DRF API View, Postman, Swagger IO...) and also to use it in your web app. For that reason, you'll receive differents types of request. On way to handle with this problem, is to create a decorator method to validate the type of request and then, in your CFA or CVB call the decorator. | |
| _instance= MyNameViewSet() | |
| _instance.endpoint_name(request,param1=1,param2=1) | |
| ''' | |
| # Request validation is like that: | |
| from functools import wraps |
| #!/bin/sh | |
| # based on https://gist.github.com/ipedrazas/9c622404fb41f2343a0db85b3821275d | |
| # delete all evicted pods from all namespaces | |
| kubectl get pods --all-namespaces | grep Evicted | awk '{print $2 " --namespace=" $1}' | xargs kubectl delete pod | |
| # delete all containers in ImagePullBackOff state from all namespaces | |
| kubectl get pods --all-namespaces | grep 'ImagePullBackOff' | awk '{print $2 " --namespace=" $1}' | xargs kubectl delete pod | |
| # delete all containers in ImagePullBackOff or ErrImagePull or Evicted state from all namespaces |
| from apiclient.discovery import build | |
| from apiclient.errors import HttpError | |
| from oauth2client.tools import argparser | |
| import pandas as pd | |
| import pprint | |
| import matplotlib.pyplot as pd | |
| DEVELOPER_KEY = "YOUR_DEVELOPER_KEY_HERE" | |
| YOUTUBE_API_SERVICE_NAME = "youtube" | |
| YOUTUBE_API_VERSION = "v3" |
| # Example which shows how to reach nested ansible variable which is partially different. | |
| # Run that plabook with ansible-playbook -e "env=test" ansible-nested-variable.yml | |
| --- | |
| # | |
| - hosts: localhost | |
| connection : ssh | |
| gather_facts: no | |
| vars: | |
| cidr_blocks: | |
| vpc_production_cidr_block: "10.10.0.0/28" |
| # /srv/salt/upgrade_the_app.sls | |
| # Example of a complex, multi-host Orchestration state that performs status checks as it goes. | |
| # Note, this is untested and is meant to serve as an example. | |
| # Run via: salt-run state.orch upgrade_the_app pillar='{nodes: [nodeA, nodeB], version: 123}' | |
| {% set nodes = salt.pillar.get('nodes', []) %} | |
| {% set all_grains = salt.saltutil.runner('cache.grains', | |
| tgt=','.join(nodes), tgt_type='list') %} | |
| {# Default version if not given at the CLI. #} |
| #! /bin/bash | |
| wordpressPath=/srv/wp01 | |
| wordpressName=wordpress01 | |
| wordpressPwd=pAssw0rd | |
| wordpressUrl=wordpress01.example.com | |
| ################################## | |
| mkdir -p "$wordpressPath"/db |
| \n | |
| ============= HOST: ==========\n | |
| \n | |
| local_ip: %{local_ip}\n | |
| local_port: %{local_port}\n | |
| remote_ip: %{remote_ip}\n | |
| remote_port: %{remote_port}\n | |
| \n | |
| ======= CONNECTION: ==========\n | |
| \n |
This documentation aims at being a quick-straight-to-the-point-hands-on AWS resources manipulation with [boto3][0].
First of all, you'll need to install [boto3][0]. Installing it along with [awscli][1] is probably a good idea as
