superseb

Deploy kubernetes-dashboard on Rancher 2.x cluster exposed using NodePort

This has been updated to install Dashboard v2.0.0, see below for pre v2.0.0 instructions

Requirements

• kubectl (https://kubernetes.io/docs/tasks/tools/install-kubectl/)

Step 1: Generate kubeconfig from the UI

Generate the kubeconfig file for your cluster using the Kubeconfig File button in the Cluster view of your cluster.

superseb

#!/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

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

ateucher

These are instructions for setting up git to authenticate with GitHub when you have 2-factor authentication set up. This authentication should be inherited by any GUI client you are using. These are intentionally brief instructions, with links to more detail in the appropriate places.

1. Download and install the git command-line client (if required).

2. Open the git bash window and introduce yourself to git (if required):

   git config --global user.name 'Firstname Lastname'
   git config --global user.email 'firstname.lastname@gov.bc.ca'
   

fliphess

from __future__ import (absolute_import, division, print_function)
__metaclass__ = type

import getpass
import logging
import logging.config
import os
import socket

try:

nickjohnson-dev

import { Component } from 'angular2/core';
import { MyWizard } from './my-wizard';
import { MyWizardStep } from './my-wizard-step';

@Component({
  selector: 'my-app',
  directives: [
    MyWizard,
    MyWizardStep,
  ],

natefoo

#!/usr/bin/env python

import logging
import sys
from time import sleep

from bioblend.galaxy import GalaxyInstance
from daemonize import Daemonize

adam-p

It's not immediately obvious how to pull down the code for a PR and test it locally. But it's pretty easy. (This assumes you have a remote for the main repo named upstream.)

Getting the PR code

1. Make note of the PR number. For example, Rod's latest is PR #37: Psiphon-Labs/psiphon-tunnel-core#37

2. Fetch the PR's pseudo-branch (or bookmark or rev pointer whatever the word is), and give it a local branch name. Here we'll name it pr37:

$ git fetch upstream pull/37/head:pr37

richardcornish

Git notes

Start

1. Install Git
2. Create a GitHub account
3. Open Terminal /Applications/Utilities/Terminal.app

Configure

piscisaureus

Locate the section for your github remote in the .git/config file. It looks like this:

[remote "origin"]
	fetch = +refs/heads/*:refs/remotes/origin/*
	url = git@github.com:joyent/node.git

Now add the line fetch = +refs/pull/*/head:refs/remotes/origin/pr/* to this section. Obviously, change the github url to match your project's URL. It ends up looking like this: