Oluwasetemi

Contentful Apollo Rest Data Source

I wrote a rest data source for one of my client's 
project to fetch data from contentful api to 
a graphql backend. For more information - https://www.apollographql.com/docs/apollo-server/data/data-sources/ 

tehmoon

#!/bin/sh
set -e

## SEE https://medium.com/@ebuschini/iptables-and-docker-95e2496f0b45

## You need to add rules in DOCKER-BLOCK AND INPUT for traffic that does not go to a container.
## You only need to add one rule if the traffic goes to the container

CWD=$(cd "$(dirname "${0}")"; pwd -P)
FILE="${CWD}/$(basename "${0}")"

lcrilly

OAuth 2.0 Token Introspection with NGINX and njs

This configuration enables NGINX to validate an authentication token against an authorization server by using OAuth 2.0 Token Introspection (RFC 7662). This solution uses the auth_request module and the NGINX JavaScript module to require authentication and perform the token introspection request.

By default, the client's authentication token is expected as a bearer token supplied in the Authorization header. If supplied elsewhere in the HTTP request, the $access_token variable must be configured to specify where to obtain the token.

Token introspection requests are authenticated. By default, the $oauth_client_id and $oauth_client_secret variables are used to perform HTTP Basic authentication with the Authorization Server. If only the $oauth_client_secret variable is specified then that value is used

nginx-gists

upstream warehouse_inventory {
    zone inventory_service 64k;
    server 10.0.0.1:80;
    server 10.0.0.2:80;
    server 10.0.0.3:80;
}

upstream warehouse_pricing {
    zone pricing_service 64k;
    server 10.0.0.7:80;

Grendel7

server {
    listen       80 default_server;
    listen       [::]:80 default_server;
    server_name  _;
    root         /home/app/html/public;
    index        index.php index.html index.htm;

    # Load configuration files for the default server block.
    include /etc/nginx/default.d/*.conf;

pzelnip

# -*- mode: ruby -*-
# vi: set ft=ruby :

# All Vagrant configuration is done below. The "2" in Vagrant.configure
# configures the configuration version (we support older styles for
# backwards compatibility). Please don't change it unless you know what
# you're doing.
Vagrant.configure("2") do |config|
  # The most common configuration options are documented and commented below.
  # For a complete reference, please see the online documentation at

thaJeztah

Docker Swarm with Macvlan, Consul and Autoscaling

TL;DR:

This will get you routable containers with IPs on your existing subnets, advertising to Consul. They will also be scalable and placed across a cluster of Swarm hosts. It's assumed that you are already running Consul, so if not, there are a ton of tutorials out there. It's also assumed you know how to install Docker and various Linux kernels.

Bonus: We add an autoscaling API called Orbiter (https://gianarb.it/blog/orbiter-the-swarm-autoscaler-moves).

I just want to run containers, like now, on my existing infrastructure and networks!

So you have an existing environment. You use Consul for service discovery. Life is good. Containers are now a thing and you want to work them in without having to worry about overlay networking or reverse proxies. You also don't want to add extra latency (as some naysayers could use it as fuel to kill your hopes and dreams). Lastly, you don't have a lot of time to invest in a complex orchestration tool, such a

jonathan-kosgei

I have been an aggressive Kubernetes evangelist over the last few years. It has been the hammer with which I have approached almost all my deployments, and the one tool I have mentioned (shoved down clients throats) in almost all my foremost communications with clients, and it was my go to choice when I was mocking my first startup (saharacluster.com).

A few weeks ago Docker 1.13 was released and I was tasked with replicating a client's Kubernetes deployment on Swarm, more specifically testing running compose on Swarm.

And it was a dream!

All our apps were already dockerised and all I had to do was make a few modificatons to an existing compose file that I had used for testing before prior said deployment on Kubernetes.

And, with the ease with which I was able to expose our endpoints, manage volumes, handle networking, deploy and tear down the setup. I in all honesty see no reason to not use Swarm. No mission-critical feature, or incredibly convenient really nice to have feature in Kubernetes that I'm go

marcuslang

Vagrant.configure("2") do |config|

  (1..3).each do |i|
    config.vm.define "node-#{i}" do |node|
      node.vm.box = "ubuntu/trusty64"
      node.vm.network "private_network", ip: "192.168.25.#{i}", auto_config: false
      node.vm.provision "shell", inline: "echo hello from node #{i}"
    end
  end
  

mike-hearn

# -*- mode: ruby -*-

# vi: set ft=ruby :

boxes = [
    {
        :name => "server1",
        :eth1 => "192.168.205.10",
        :mem => "1024",
        :cpu => "1"