How-to kubectl LoadBalancer and configure Nginx Ingress controller for a GCP Cluster

Have you ever wondered you could have written your own LoadBalancer for K8s instead of going through all the documentation out there , well then look no further! I will walk you through the setup for bringing up a Nginx Ingress Controller and a Layer 4 LoadBalancer on a Kubernetes GCP cluster .

Kubernetes has decoupled the cloud specific control loops from kube-controller . So if you need LoadBalancers, Node Controls on the specific cloud platform then you have to install the cloud controller manager separately . This still does not support the storage on those nodes , Storage for one is still handled by the kube-controller . The modification for Stateful set on a specific cloud can be found here .

Now lets look at how to install and configure the cloud-controller-manager.

Prerequisite: All the kubelets running on all of the nodes should have a “cloud-provider=external” flag enabled . Also the “cloud-config” flag should point to a file which should have the following format . The “node-tags” has to be the same on all the nodes . The Key is the API key to access the GCP Cloud API from the GCP IM credentials tab .

[Global]
project-id = rosy-cache-200605
node-tags = kubernetes
key = AIza**************MVZhpLp62GkA

The kube-api-server and the kube-controller **should not **have the “cloud-provider” flag . If you have it then just comment it out or remove it from the config files .

Setup the Master node as shown below: This step is already covered in this article, which needs tweaking in setting up the required flags . As a recap if you are starting afresh then just do these steps……

From your home directory : Installing or Upgrading python
$ mkdir pyup;cd pyup;git init;git pull https://github.com/rangapv/pyUpgrade.git;./py.sh

Again from your home directory : Installing docker
$ mkdir doker;cd doker;git init;git pull https://github.com/rangapv/doker.git;./dock.sh
Again from your home directory : pulling all the required k8s YAML definitions from the github
$ mkdir adm;cd adm;git init;git pull https://github.com/rangapv/k8s.git
$ ls
ccm  kube_adm  kube_dash  kube_flannel  kube_node  pods Readme

Now lets install the different k8s component for the Master Node :

$ cd kube_adm
$ ls
adm_install.sh
$./adm_install.sh

and DO NOT execute the kubeadm init command which you got in the screen output from the above command , that is for Kubeadm install without modifications — plain vanilla setup . Instead we will create a config file and execute the kubeadm init with flags in Step 3 below .

2. Copy the gce.conf to /etc/kubernetes folder ; This file should have the project-id of you GCP account and also the API key for your IAM account which can be got from the GCP console

$ sudo vi /etc/kubernetes/gce.conf
[Global]
project-id = rosy-cache-200605
node-tags = kubernetes
key = AIzaSy*****************************p62GkA

3. Install the Master Node cluster using kubeadm init with the configuration changes in the “adm-conf” file which is listed below

---
	apiVersion: kubeadm.k8s.io/v1beta1
	kind: InitConfiguration
	bootstrapTokens:
	- token:
	  ttl: "0"
	nodeRegistration:
	 kubeletExtraArgs:
	  cloud-provider: "external"
	  cloud-config: /etc/kubernetes/gce.conf
	---
	apiVersion: kubeadm.k8s.io/v1beta2
	kind: ClusterConfiguration
	kubernetesVersion: v1.18.0
	apiServer:
	  extraArgs:
	    enable-admission-plugins: NodeRestriction,AlwaysPullImages,DefaultStorageClass
	    authorization-mode: Node,RBAC
	controllerManager:
	  extraArgs:
	    allocate-node-cidrs: "true"
	    cluster-cidr: 10.244.0.0/16
	    cloud-config: /etc/kubernetes/gce.conf
	    enable-taint-manager: "false"
	    cloud-provider: "external"

$ sudo kubeadm init --config=./adm-conf.yaml

This will give a “kube adm join …” output as shown below
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config.
.
.
kubeadm join 10.128.0.52:6443 --token bw1oyz.h5mfl6tdicnhmtf1
–discovery-token-ca-cert-hash sha256:c121****************27245d5b4d455f1c03f87eaf7ce4b7f30098107b


Copy the kubeadm join command in a notepad++ which is to be used later for the worker Nodes to join the cluster . Copy the Master config file to you $HOME/.kube/config

4\. Installing the network flannel : From the “git pull” of step-1 above ; the adm directory has a “kube_flannel” sub folder with the flannel YAML , Apply it .

$ kubectl apply -f ./kube-flannel.yml
podsecuritypolicy.policy/psp.flannel.unprivileged created
clusterrole.rbac.authorization.k8s.io/flannel created
clusterrolebinding.rbac.authorization.k8s.io/flannel created
serviceaccount/flannel created
configmap/kube-flannel-cfg created
daemonset.apps/kube-flannel-ds-amd64 created
daemonset.apps/kube-flannel-ds-arm64 created
daemonset.apps/kube-flannel-ds-arm created
daemonset.apps/kube-flannel-ds-ppc64le created
daemonset.apps/kube-flannel-ds-s390x created

#load-balancing #distributed-systems #kubernetes #nginx #ingress

What is GEEK

Buddha Community

How-to kubectl LoadBalancer and configure Nginx Ingress controller for a GCP Cluster

Arno Bradtke

1598032740

How-to kubectl LoadBalancer and configure Nginx Ingress controller for a GCP Cluster

Have you ever wondered you could have written your own LoadBalancer for K8s instead of going through all the documentation out there , well then look no further! I will walk you through the setup for bringing up a Nginx Ingress Controller and a Layer 4 LoadBalancer on a Kubernetes GCP cluster .

Kubernetes has decoupled the cloud specific control loops from kube-controller . So if you need LoadBalancers, Node Controls on the specific cloud platform then you have to install the cloud controller manager separately . This still does not support the storage on those nodes , Storage for one is still handled by the kube-controller . The modification for Stateful set on a specific cloud can be found here .

Now lets look at how to install and configure the cloud-controller-manager.

Prerequisite: All the kubelets running on all of the nodes should have a “cloud-provider=external” flag enabled . Also the “cloud-config” flag should point to a file which should have the following format . The “node-tags” has to be the same on all the nodes . The Key is the API key to access the GCP Cloud API from the GCP IM credentials tab .

[Global]
project-id = rosy-cache-200605
node-tags = kubernetes
key = AIza**************MVZhpLp62GkA

The kube-api-server and the kube-controller **should not **have the “cloud-provider” flag . If you have it then just comment it out or remove it from the config files .

Setup the Master node as shown below: This step is already covered in this article, which needs tweaking in setting up the required flags . As a recap if you are starting afresh then just do these steps……

From your home directory : Installing or Upgrading python
$ mkdir pyup;cd pyup;git init;git pull https://github.com/rangapv/pyUpgrade.git;./py.sh

Again from your home directory : Installing docker
$ mkdir doker;cd doker;git init;git pull https://github.com/rangapv/doker.git;./dock.sh
Again from your home directory : pulling all the required k8s YAML definitions from the github
$ mkdir adm;cd adm;git init;git pull https://github.com/rangapv/k8s.git
$ ls
ccm  kube_adm  kube_dash  kube_flannel  kube_node  pods Readme

Now lets install the different k8s component for the Master Node :

$ cd kube_adm
$ ls
adm_install.sh
$./adm_install.sh

and DO NOT execute the kubeadm init command which you got in the screen output from the above command , that is for Kubeadm install without modifications — plain vanilla setup . Instead we will create a config file and execute the kubeadm init with flags in Step 3 below .

2. Copy the gce.conf to /etc/kubernetes folder ; This file should have the project-id of you GCP account and also the API key for your IAM account which can be got from the GCP console

$ sudo vi /etc/kubernetes/gce.conf
[Global]
project-id = rosy-cache-200605
node-tags = kubernetes
key = AIzaSy*****************************p62GkA

3. Install the Master Node cluster using kubeadm init with the configuration changes in the “adm-conf” file which is listed below

---
	apiVersion: kubeadm.k8s.io/v1beta1
	kind: InitConfiguration
	bootstrapTokens:
	- token:
	  ttl: "0"
	nodeRegistration:
	 kubeletExtraArgs:
	  cloud-provider: "external"
	  cloud-config: /etc/kubernetes/gce.conf
	---
	apiVersion: kubeadm.k8s.io/v1beta2
	kind: ClusterConfiguration
	kubernetesVersion: v1.18.0
	apiServer:
	  extraArgs:
	    enable-admission-plugins: NodeRestriction,AlwaysPullImages,DefaultStorageClass
	    authorization-mode: Node,RBAC
	controllerManager:
	  extraArgs:
	    allocate-node-cidrs: "true"
	    cluster-cidr: 10.244.0.0/16
	    cloud-config: /etc/kubernetes/gce.conf
	    enable-taint-manager: "false"
	    cloud-provider: "external"

$ sudo kubeadm init --config=./adm-conf.yaml

This will give a “kube adm join …” output as shown below
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config.
.
.
kubeadm join 10.128.0.52:6443 --token bw1oyz.h5mfl6tdicnhmtf1
–discovery-token-ca-cert-hash sha256:c121****************27245d5b4d455f1c03f87eaf7ce4b7f30098107b


Copy the kubeadm join command in a notepad++ which is to be used later for the worker Nodes to join the cluster . Copy the Master config file to you $HOME/.kube/config

4\. Installing the network flannel : From the “git pull” of step-1 above ; the adm directory has a “kube_flannel” sub folder with the flannel YAML , Apply it .

$ kubectl apply -f ./kube-flannel.yml
podsecuritypolicy.policy/psp.flannel.unprivileged created
clusterrole.rbac.authorization.k8s.io/flannel created
clusterrolebinding.rbac.authorization.k8s.io/flannel created
serviceaccount/flannel created
configmap/kube-flannel-cfg created
daemonset.apps/kube-flannel-ds-amd64 created
daemonset.apps/kube-flannel-ds-arm64 created
daemonset.apps/kube-flannel-ds-arm created
daemonset.apps/kube-flannel-ds-ppc64le created
daemonset.apps/kube-flannel-ds-s390x created

#load-balancing #distributed-systems #kubernetes #nginx #ingress

Autumn Blick

1603600800

NGINX Announces Eight Solutions that Let Developers Run Safely with Scissors

Technology is hard. As technologists, I think we like it that way. It’s built‑in job security, right? Well, unfortunately, the modern application world has become unproductively hard. We need to make it easier.

That’s why I like describing the current developer paradox as the need to run safely with scissors.

NGINX Balances Developer Choice with Infrastructure Guardrails

Running with scissors is a simple metaphor for what is the admittedly difficult ask we make of software engineers. Developers need to run. Time to market and feature velocity are critical to the success of digital businesses. As a result, we don’t want to encumber developers with processes or technology choices that slow them down. Instead we empower them to pick tools and stacks that let them deliver code to customers as quickly as possible.

But there’s a catch. In the world of fast releases, multiple daily (or hourly or minutely!) changes, and fail‑fast development, we risk introducing application downtime into digital experiences – that risk is the metaphorical scissors that make it dangerous to run fast. On some level we know it’s wrong to make developers run with scissors. But the speed upside trumps the downtime downside.

That frames the dilemma of our era: we need our developers to run with scissors, but we don’t want anybody to get hurt. Is there a solution?

At NGINX, the answer is “yes”. I’m excited to announce eight new or significantly enhanced solutions built to unleash developer speed without sacrificing the governance, visibility, and control infrastructure teams require.

Load Balancing and Security DNS Solutions Empower Self‑Service

As my colleague, Gus Robertson, eloquently points out in his recent blog The Essence of Sprint Is Speed, self‑service is an important part of developer empowerment. He talks about developers as the engines of digital transformation. And if they’re not presented with easy-to-use, capable tools, they take matters into their own hands. The result is shadow IT and significant infrastructure risk.

Self‑service turns this on its head. It provides infrastructure teams with a way to release the application delivery and security technologies that developers need for A/B, canary, blue‑green, and circuit‑breaker patterns. But it does so within the guardrails that ensure the consistency, reliability, and security that ensure your apps remain running once in production.

#blog #news #opinion #red hat #nginx controller #nginx app protect #nginx sprint 2020 #nginx ingress controller #nginx service mesh #f5 dns cloud services #nginx analytics cloud service

React Native Dev

1652543820

Background Fetch for React Native Apps

react-native-background-fetch

Background Fetch is a very simple plugin which attempts to awaken an app in the background about every 15 minutes, providing a short period of background running-time. This plugin will execute your provided callbackFn whenever a background-fetch event occurs.

There is no way to increase the rate which a fetch-event occurs and this plugin sets the rate to the most frequent possible — you will never receive an event faster than 15 minutes. The operating-system will automatically throttle the rate the background-fetch events occur based upon usage patterns. Eg: if user hasn't turned on their phone for a long period of time, fetch events will occur less frequently or if an iOS user disables background refresh they may not happen at all.

:new: Background Fetch now provides a scheduleTask method for scheduling arbitrary "one-shot" or periodic tasks.

iOS

There is no way to increase the rate which a fetch-event occurs and this plugin sets the rate to the most frequent possible — you will never receive an event faster than 15 minutes. The operating-system will automatically throttle the rate the background-fetch events occur based upon usage patterns. Eg: if user hasn't turned on their phone for a long period of time, fetch events will occur less frequently.
scheduleTask seems only to fire when the device is plugged into power.
⚠️ When your app is terminated, iOS no longer fires events — There is no such thing as stopOnTerminate: false for iOS.
iOS can take days before Apple's machine-learning algorithm settles in and begins regularly firing events. Do not sit staring at your logs waiting for an event to fire. If your simulated events work, that's all you need to know that everything is correctly configured.
If the user doesn't open your iOS app for long periods of time, iOS will stop firing events.

Android

The Android plugin provides a HeadlessJS implementation allowing you to continue handling events even after app-termination (see @config enableHeadless)

Installing the plugin

⚠️ If you have a previous version of react-native-background-fetch < 2.7.0 installed into react-native >= 0.60, you should first unlink your previous version as react-native link is no longer required.

$ react-native unlink react-native-background-fetch

With `yarn`

$ yarn add react-native-background-fetch

With `npm`

$ npm install --save react-native-background-fetch

Setup Guides

iOS Setup

`react-native >= 0.60`

Auto-linking Setup

Android Setup

`react-native >= 0.60`

Auto-linking Setup

Example

ℹ️ This repo contains its own Example App. See /example

import React from 'react';
import {
  SafeAreaView,
  StyleSheet,
  ScrollView,
  View,
  Text,
  FlatList,
  StatusBar,
} from 'react-native';

import {
  Header,
  Colors
} from 'react-native/Libraries/NewAppScreen';

import BackgroundFetch from "react-native-background-fetch";

class App extends React.Component {
  constructor(props) {
    super(props);
    this.state = {
      events: []
    };
  }

  componentDidMount() {
    // Initialize BackgroundFetch ONLY ONCE when component mounts.
    this.initBackgroundFetch();
  }

  async initBackgroundFetch() {
    // BackgroundFetch event handler.
    const onEvent = async (taskId) => {
      console.log('[BackgroundFetch] task: ', taskId);
      // Do your background work...
      await this.addEvent(taskId);
      // IMPORTANT:  You must signal to the OS that your task is complete.
      BackgroundFetch.finish(taskId);
    }

    // Timeout callback is executed when your Task has exceeded its allowed running-time.
    // You must stop what you're doing immediately BackgroundFetch.finish(taskId)
    const onTimeout = async (taskId) => {
      console.warn('[BackgroundFetch] TIMEOUT task: ', taskId);
      BackgroundFetch.finish(taskId);
    }

    // Initialize BackgroundFetch only once when component mounts.
    let status = await BackgroundFetch.configure({minimumFetchInterval: 15}, onEvent, onTimeout);

    console.log('[BackgroundFetch] configure status: ', status);
  }

  // Add a BackgroundFetch event to <FlatList>
  addEvent(taskId) {
    // Simulate a possibly long-running asynchronous task with a Promise.
    return new Promise((resolve, reject) => {
      this.setState(state => ({
        events: [...state.events, {
          taskId: taskId,
          timestamp: (new Date()).toString()
        }]
      }));
      resolve();
    });
  }

  render() {
    return (
      <>
        <StatusBar barStyle="dark-content" />
        <SafeAreaView>
          <ScrollView
            contentInsetAdjustmentBehavior="automatic"
            style={styles.scrollView}>
            <Header />

            <View style={styles.body}>
              <View style={styles.sectionContainer}>
                <Text style={styles.sectionTitle}>BackgroundFetch Demo</Text>
              </View>
            </View>
          </ScrollView>
          <View style={styles.sectionContainer}>
            <FlatList
              data={this.state.events}
              renderItem={({item}) => (<Text>[{item.taskId}]: {item.timestamp}</Text>)}
              keyExtractor={item => item.timestamp}
            />
          </View>
        </SafeAreaView>
      </>
    );
  }
}

const styles = StyleSheet.create({
  scrollView: {
    backgroundColor: Colors.lighter,
  },
  body: {
    backgroundColor: Colors.white,
  },
  sectionContainer: {
    marginTop: 32,
    paddingHorizontal: 24,
  },
  sectionTitle: {
    fontSize: 24,
    fontWeight: '600',
    color: Colors.black,
  },
  sectionDescription: {
    marginTop: 8,
    fontSize: 18,
    fontWeight: '400',
    color: Colors.dark,
  },
});

export default App;

Executing Custom Tasks

In addition to the default background-fetch task defined by BackgroundFetch.configure, you may also execute your own arbitrary "oneshot" or periodic tasks (iOS requires additional Setup Instructions). However, all events will be fired into the Callback provided to BackgroundFetch#configure:

⚠️ iOS:

scheduleTask on iOS seems only to run when the device is plugged into power.
scheduleTask on iOS are designed for low-priority tasks, such as purging cache files — they tend to be unreliable for mission-critical tasks. scheduleTask will never run as frequently as you want.
The default fetch event is much more reliable and fires far more often.
scheduleTask on iOS stop when the user terminates the app. There is no such thing as stopOnTerminate: false for iOS.

// Step 1:  Configure BackgroundFetch as usual.
let status = await BackgroundFetch.configure({
  minimumFetchInterval: 15
}, async (taskId) => {  // <-- Event callback
  // This is the fetch-event callback.
  console.log("[BackgroundFetch] taskId: ", taskId);

  // Use a switch statement to route task-handling.
  switch (taskId) {
    case 'com.foo.customtask':
      print("Received custom task");
      break;
    default:
      print("Default fetch task");
  }
  // Finish, providing received taskId.
  BackgroundFetch.finish(taskId);
}, async (taskId) => {  // <-- Task timeout callback
  // This task has exceeded its allowed running-time.
  // You must stop what you're doing and immediately .finish(taskId)
  BackgroundFetch.finish(taskId);
});

// Step 2:  Schedule a custom "oneshot" task "com.foo.customtask" to execute 5000ms from now.
BackgroundFetch.scheduleTask({
  taskId: "com.foo.customtask",
  forceAlarmManager: true,
  delay: 5000  // <-- milliseconds
});

API Documentation

Config

Common Options

`@param {Integer} minimumFetchInterval [15]`

The minimum interval in minutes to execute background fetch events. Defaults to 15 minutes. Note: Background-fetch events will never occur at a frequency higher than every 15 minutes. Apple uses a secret algorithm to adjust the frequency of fetch events, presumably based upon usage patterns of the app. Fetch events can occur less often than your configured minimumFetchInterval.

`@param {Integer} delay (milliseconds)`

ℹ️ Valid only for BackgroundFetch.scheduleTask. The minimum number of milliseconds in future that task should execute.

`@param {Boolean} periodic [false]`

ℹ️ Valid only for BackgroundFetch.scheduleTask. Defaults to false. Set true to execute the task repeatedly. When false, the task will execute just once.

Android Options

`@config {Boolean} stopOnTerminate [true]`

Set false to continue background-fetch events after user terminates the app. Default to true.

`@config {Boolean} startOnBoot [false]`

Set true to initiate background-fetch events when the device is rebooted. Defaults to false.

❗ NOTE: startOnBoot requires stopOnTerminate: false.

`@config {Boolean} forceAlarmManager [false]`

By default, the plugin will use Android's JobScheduler when possible. The JobScheduler API prioritizes for battery-life, throttling task-execution based upon device usage and battery level.

Configuring forceAlarmManager: true will bypass JobScheduler to use Android's older AlarmManager API, resulting in more accurate task-execution at the cost of higher battery usage.

let status = await BackgroundFetch.configure({
  minimumFetchInterval: 15,
  forceAlarmManager: true
}, async (taskId) => {  // <-- Event callback
  console.log("[BackgroundFetch] taskId: ", taskId);
  BackgroundFetch.finish(taskId);
}, async (taskId) => {  // <-- Task timeout callback
  // This task has exceeded its allowed running-time.
  // You must stop what you're doing and immediately .finish(taskId)
  BackgroundFetch.finish(taskId);
});
.
.
.
// And with with #scheduleTask
BackgroundFetch.scheduleTask({
  taskId: 'com.foo.customtask',
  delay: 5000,       // milliseconds
  forceAlarmManager: true,
  periodic: false
});

`@config {Boolean} enableHeadless [false]`

Set true to enable React Native's Headless JS mechanism, for handling fetch events after app termination.

📂 index.js (MUST BE IN index.js):

import BackgroundFetch from "react-native-background-fetch";

let MyHeadlessTask = async (event) => {
  // Get task id from event {}:
  let taskId = event.taskId;
  let isTimeout = event.timeout;  // <-- true when your background-time has expired.
  if (isTimeout) {
    // This task has exceeded its allowed running-time.
    // You must stop what you're doing immediately finish(taskId)
    console.log('[BackgroundFetch] Headless TIMEOUT:', taskId);
    BackgroundFetch.finish(taskId);
    return;
  }
  console.log('[BackgroundFetch HeadlessTask] start: ', taskId);

  // Perform an example HTTP request.
  // Important:  await asychronous tasks when using HeadlessJS.
  let response = await fetch('https://reactnative.dev/movies.json');
  let responseJson = await response.json();
  console.log('[BackgroundFetch HeadlessTask] response: ', responseJson);

  // Required:  Signal to native code that your task is complete.
  // If you don't do this, your app could be terminated and/or assigned
  // battery-blame for consuming too much time in background.
  BackgroundFetch.finish(taskId);
}

// Register your BackgroundFetch HeadlessTask
BackgroundFetch.registerHeadlessTask(MyHeadlessTask);

`@config {integer} requiredNetworkType [BackgroundFetch.NETWORK_TYPE_NONE]`

Set basic description of the kind of network your job requires.

If your job doesn't need a network connection, you don't need to use this option as the default value is BackgroundFetch.NETWORK_TYPE_NONE.

NetworkType	Description
`BackgroundFetch.NETWORK_TYPE_NONE`	This job doesn't care about network constraints, either any or none.
`BackgroundFetch.NETWORK_TYPE_ANY`	This job requires network connectivity.
`BackgroundFetch.NETWORK_TYPE_CELLULAR`	This job requires network connectivity that is a cellular network.
`BackgroundFetch.NETWORK_TYPE_UNMETERED`	This job requires network connectivity that is unmetered. Most WiFi networks are unmetered, as in "you can upload as much as you like".
`BackgroundFetch.NETWORK_TYPE_NOT_ROAMING`	This job requires network connectivity that is not roaming (being outside the country of origin)

`@config {Boolean} requiresBatteryNotLow [false]`

Specify that to run this job, the device's battery level must not be low.

This defaults to false. If true, the job will only run when the battery level is not low, which is generally the point where the user is given a "low battery" warning.

`@config {Boolean} requiresStorageNotLow [false]`

Specify that to run this job, the device's available storage must not be low.

This defaults to false. If true, the job will only run when the device is not in a low storage state, which is generally the point where the user is given a "low storage" warning.

`@config {Boolean} requiresCharging [false]`

Specify that to run this job, the device must be charging (or be a non-battery-powered device connected to permanent power, such as Android TV devices). This defaults to false.

`@config {Boolean} requiresDeviceIdle [false]`

When set true, ensure that this job will not run if the device is in active use.

The default state is false: that is, the for the job to be runnable even when someone is interacting with the device.

This state is a loose definition provided by the system. In general, it means that the device is not currently being used interactively, and has not been in use for some time. As such, it is a good time to perform resource heavy jobs. Bear in mind that battery usage will still be attributed to your application, and shown to the user in battery stats.

Methods

Method Name	Arguments	Returns	Notes
`configure`	`{FetchConfig}`, `callbackFn`, `timeoutFn`	`Promise<BackgroundFetchStatus>`	Configures the plugin's `callbackFn` and `timeoutFn`. This callback will fire each time a background-fetch event occurs in addition to events from `#scheduleTask`. The `timeoutFn` will be called when the OS reports your task is nearing the end of its allowed background-time.
`scheduleTask`	`{TaskConfig}`	`Promise<boolean>`	Executes a custom task. The task will be executed in the same `Callback` function provided to `#configure`.
`status`	`callbackFn`	`Promise<BackgroundFetchStatus>`	Your callback will be executed with the current `status (Integer)` `0: Restricted`, `1: Denied`, `2: Available`. These constants are defined as `BackgroundFetch.STATUS_RESTRICTED`, `BackgroundFetch.STATUS_DENIED`, `BackgroundFetch.STATUS_AVAILABLE` (NOTE: Android will always return `STATUS_AVAILABLE`)
`finish`	`String taskId`	`Void`	You MUST call this method in your `callbackFn` provided to `#configure` in order to signal to the OS that your task is complete. iOS provides only 30s of background-time for a fetch-event -- if you exceed this 30s, iOS will kill your app.
`start`	`none`	`Promise<BackgroundFetchStatus>`	Start the background-fetch API. Your `callbackFn` provided to `#configure` will be executed each time a background-fetch event occurs. NOTE the `#configure` method automatically calls `#start`. You do not have to call this method after you `#configure` the plugin
`stop`	`[taskId:String]`	`Promise<boolean>`	Stop the background-fetch API and all `#scheduleTask` from firing events. Your `callbackFn` provided to `#configure` will no longer be executed. If you provide an optional `taskId`, only that `#scheduleTask` will be stopped.

Debugging

iOS

🆕 `BGTaskScheduler` API for iOS 13+

⚠️ At the time of writing, the new task simulator does not yet work in Simulator; Only real devices.
See Apple docs Starting and Terminating Tasks During Development
After running your app in XCode, Click the [||] button to initiate a Breakpoint.
In the console (lldb), paste the following command (Note: use cursor up/down keys to cycle through previously run commands):

e -l objc -- (void)[[BGTaskScheduler sharedScheduler] _simulateLaunchForTaskWithIdentifier:@"com.transistorsoft.fetch"]

Click the [ > ] button to continue. The task will execute and the Callback function provided to BackgroundFetch.configure will receive the event.

Simulating task-timeout events

Only the new BGTaskScheduler api supports simulated task-timeout events. To simulate a task-timeout, your fetchCallback must not call BackgroundFetch.finish(taskId):

let status = await BackgroundFetch.configure({
  minimumFetchInterval: 15
}, async (taskId) => {  // <-- Event callback.
  // This is the task callback.
  console.log("[BackgroundFetch] taskId", taskId);
  //BackgroundFetch.finish(taskId); // <-- Disable .finish(taskId) when simulating an iOS task timeout
}, async (taskId) => {  // <-- Event timeout callback
  // This task has exceeded its allowed running-time.
  // You must stop what you're doing and immediately .finish(taskId)
  print("[BackgroundFetch] TIMEOUT taskId:", taskId);
  BackgroundFetch.finish(taskId);
});

Now simulate an iOS task timeout as follows, in the same manner as simulating an event above:

e -l objc -- (void)[[BGTaskScheduler sharedScheduler] _simulateExpirationForTaskWithIdentifier:@"com.transistorsoft.fetch"]

Old `BackgroundFetch` API

Simulate background fetch events in XCode using Debug->Simulate Background Fetch
iOS can take some hours or even days to start a consistently scheduling background-fetch events since iOS schedules fetch events based upon the user's patterns of activity. If Simulate Background Fetch works, your can be sure that everything is working fine. You just need to wait.

Android

Observe plugin logs in $ adb logcat:

$ adb logcat *:S ReactNative:V ReactNativeJS:V TSBackgroundFetch:V

Simulate a background-fetch event on a device (insert <your.application.id>) (only works for sdk 21+:

$ adb shell cmd jobscheduler run -f <your.application.id> 999

For devices with sdk <21, simulate a "Headless JS" event with (insert <your.application.id>)

$ adb shell am broadcast -a <your.application.id>.event.BACKGROUND_FETCH

Download Details:
Author: transistorsoft
Source Code: https://github.com/transistorsoft/react-native-background-fetch
License: MIT license

#react #reactnative #mobileapp #javascript

Mikel Okuneva

1600894800

Performance Testing NGINX Ingress Controllers in a Dynamic Kubernetes Cloud Environment

As more and more enterprises run containerized apps in production, Kubernetes continues to solidify its position as the standard tool for container orchestration. At the same time, demand for cloud computing has been pulled forward by a couple of years because work-at-home initiatives prompted by the COVID‑19 pandemic have accelerated the growth of Internet traffic. Companies are working rapidly to upgrade their infrastructure because their customers are experiencing major network outages and overloads.

To achieve the required level of performance in cloud‑based microservices environments, you need rapid, fully dynamic software that harnesses the scalability and performance of the next‑generation hyperscale data centers. Many organizations that use Kubernetes to manage containers depend on an NGINX‑based Ingress controller to deliver their apps to users.

#blog #tech #ingress controller #nginx ingress controller

Christa Stehr

1602964260

50+ Useful Kubernetes Tools for 2020 - Part 2

Introduction

Last year, we provided a list of Kubernetes tools that proved so popular we have decided to curate another list of some useful additions for working with the platform—among which are many tools that we personally use here at Caylent. Check out the original tools list here in case you missed it.

According to a recent survey done by Stackrox, the dominance Kubernetes enjoys in the market continues to be reinforced, with 86% of respondents using it for container orchestration.

(State of Kubernetes and Container Security, 2020)

And as you can see below, more and more companies are jumping into containerization for their apps. If you’re among them, here are some tools to aid you going forward as Kubernetes continues its rapid growth.

(State of Kubernetes and Container Security, 2020)

#blog #tools #amazon elastic kubernetes service #application security #aws kms #botkube #caylent #cli #container monitoring #container orchestration tools #container security #containers #continuous delivery #continuous deployment #continuous integration #contour #developers #development #developments #draft #eksctl #firewall #gcp #github #harbor #helm #helm charts #helm-2to3 #helm-aws-secret-plugin #helm-docs #helm-operator-get-started #helm-secrets #iam #json #k-rail #k3s #k3sup #k8s #keel.sh #keycloak #kiali #kiam #klum #knative #krew #ksniff #kube #kube-prod-runtime #kube-ps1 #kube-scan #kube-state-metrics #kube2iam #kubeapps #kubebuilder #kubeconfig #kubectl #kubectl-aws-secrets #kubefwd #kubernetes #kubernetes command line tool #kubernetes configuration #kubernetes deployment #kubernetes in development #kubernetes in production #kubernetes ingress #kubernetes interfaces #kubernetes monitoring #kubernetes networking #kubernetes observability #kubernetes plugins #kubernetes secrets #kubernetes security #kubernetes security best practices #kubernetes security vendors #kubernetes service discovery #kubernetic #kubesec #kubeterminal #kubeval #kudo #kuma #microsoft azure key vault #mozilla sops #octant #octarine #open source #palo alto kubernetes security #permission-manager #pgp #rafay #rakess #rancher #rook #secrets operations #serverless function #service mesh #shell-operator #snyk #snyk container #sonobuoy #strongdm #tcpdump #tenkai #testing #tigera #tilt #vert.x #wireshark #yaml

How-to kubectl LoadBalancer and configure Nginx Ingress controller for a GCP Cluster

What is GEEK

Buddha Community

How-to kubectl LoadBalancer and configure Nginx Ingress controller for a GCP Cluster

NGINX Announces Eight Solutions that Let Developers Run Safely with Scissors

NGINX Balances Developer Choice with Infrastructure Guardrails

Load Balancing and Security DNS Solutions Empower Self‑Service

Background Fetch for React Native Apps

react-native-background-fetch

iOS

Android

Installing the plugin

With yarn

With npm

Setup Guides

iOS Setup

react-native >= 0.60

Android Setup

react-native >= 0.60

Example

Executing Custom Tasks

⚠️ iOS:

Config

Common Options

@param {Integer} minimumFetchInterval [15]

@param {Integer} delay (milliseconds)

@param {Boolean} periodic [false]

Android Options

@config {Boolean} stopOnTerminate [true]

@config {Boolean} startOnBoot [false]

@config {Boolean} forceAlarmManager [false]

@config {Boolean} enableHeadless [false]

@config {integer} requiredNetworkType [BackgroundFetch.NETWORK_TYPE_NONE]

@config {Boolean} requiresBatteryNotLow [false]

@config {Boolean} requiresStorageNotLow [false]

@config {Boolean} requiresCharging [false]

@config {Boolean} requiresDeviceIdle [false]

Methods

Debugging

iOS

🆕 BGTaskScheduler API for iOS 13+

Simulating task-timeout events

Old BackgroundFetch API

Android

Performance Testing NGINX Ingress Controllers in a Dynamic Kubernetes Cloud Environment

50+ Useful Kubernetes Tools for 2020 - Part 2

Introduction

With `yarn`

With `npm`

`react-native >= 0.60`

`react-native >= 0.60`

`@param {Integer} minimumFetchInterval [15]`

`@param {Integer} delay (milliseconds)`

`@param {Boolean} periodic [false]`

`@config {Boolean} stopOnTerminate [true]`

`@config {Boolean} startOnBoot [false]`

`@config {Boolean} forceAlarmManager [false]`

`@config {Boolean} enableHeadless [false]`

`@config {integer} requiredNetworkType [BackgroundFetch.NETWORK_TYPE_NONE]`

`@config {Boolean} requiresBatteryNotLow [false]`

`@config {Boolean} requiresStorageNotLow [false]`

`@config {Boolean} requiresCharging [false]`

`@config {Boolean} requiresDeviceIdle [false]`

🆕 `BGTaskScheduler` API for iOS 13+

Old `BackgroundFetch` API