InfluxDB Service Configuration for Docker Compose

Use example below to setup InfluxDB docker container. You can then access to GUI from your browser via http://{network-gateway-ip or container-ip}:8086 with influxdb:influxdb.

Service

version: '3'

services:

    influxdb:
        build:
            context: ./docker/influxdb
        hostname: influxdb
        ports:
            - 8086:8086
        volumes:
          - ./var/docker/data/influxdb:/var/lib/influxdb:cached
        environment:
            INFLUXDB_USER: influxdb
            INFLUXDB_USER_PASSWORD: influxdb

#docker #influxdb

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

Iliana Welch

1595249460

Docker Explained: Docker Architecture | Docker Registries

Following the second video about Docker basics, in this video, I explain Docker architecture and explain the different building blocks of the docker engine; docker client, API, Docker Daemon. I also explain what a docker registry is and I finish the video with a demo explaining and illustrating how to use Docker hub

In this video lesson you will learn:

What is Docker Host
What is Docker Engine
Learn about Docker Architecture
Learn about Docker client and Docker Daemon
Docker Hub and Registries
Simple demo to understand using images from registries

#docker #docker hub #docker host #docker engine #docker architecture #api

Haylie Conn

1618458480

InfluxDB Service Configuration for Docker Compose

Use example below to setup InfluxDB docker container. You can then access to GUI from your browser via http://{network-gateway-ip or container-ip}:8086 with influxdb:influxdb.

Service

version: '3'

services:

    influxdb:
        build:
            context: ./docker/influxdb
        hostname: influxdb
        ports:
            - 8086:8086
        volumes:
          - ./var/docker/data/influxdb:/var/lib/influxdb:cached
        environment:
            INFLUXDB_USER: influxdb
            INFLUXDB_USER_PASSWORD: influxdb

#docker #influxdb

Cayla Erdman

1599914520

Apache/Airflow and PostgreSQL with Docker and Docker Compose

Hello, in this post I will show you how to set up official Apache/Airflow with PostgreSQL and LocalExecutor using docker and docker-compose. In this post, I won’t be going through Airflow, what it is, and how it is used. Please checktheofficial documentation for more information about that.

Before setting up and running Apache Airflow, please install Docker and Docker Compose.

For those in hurry…

In this chapter, I will show you files and directories which are needed to run airflow and in the next chapter, I will go file by file, line by line explaining what is going on.

Firstly, in the root directory create three more directories: dags, logs, and scripts. Further, create following files: **.env, docker-compose.yml, entrypoint.sh **and **dummy_dag.py. **Please make sure those files and directories follow the structure below.

#project structure

root/
├── dags/
│   └── dummy_dag.py
├── scripts/
│   └── entrypoint.sh
├── logs/
├── .env
└── docker-compose.yml

Created files should contain the following:

#docker-compose.yml

version: '3.8'
services:
    postgres:
        image: postgres
        environment:
            - POSTGRES_USER=airflow
            - POSTGRES_PASSWORD=airflow
            - POSTGRES_DB=airflow
    scheduler:
        image: apache/airflow
        command: scheduler
        restart_policy:
            condition: on-failure
        depends_on:
            - postgres
        env_file:
            - .env
        volumes:
            - ./dags:/opt/airflow/dags
            - ./logs:/opt/airflow/logs
    webserver:
        image: apache/airflow
        entrypoint: ./scripts/entrypoint.sh
        restart_policy:
            condition: on-failure
        depends_on:
            - postgres
            - scheduler
        env_file:
            - .env
        volumes:
            - ./dags:/opt/airflow/dags
            - ./logs:/opt/airflow/logs
            - ./scripts:/opt/airflow/scripts
        ports:
            - "8080:8080"

#entrypoint.sh
#!/usr/bin/env bash
airflow initdb
airflow webserver

#.env
AIRFLOW__CORE__SQL_ALCHEMY_CONN=postgresql+psycopg2://airflow:airflow@postgres/airflow
AIRFLOW__CORE__EXECUTOR=LocalExecutor

#dummy_dag.py
from airflow import DAG
from airflow.operators.dummy_operator import DummyOperator
from datetime import datetime
with DAG('example_dag', start_date=datetime(2016, 1, 1)) as dag:
    op = DummyOperator(task_id='op')

Positioning in the root directory and executing “docker-compose up” in the terminal should make airflow accessible on localhost:8080. Image bellow shows the final result.

If you encounter permission errors, please run “chmod -R 777” on all subdirectories, e.g. “chmod -R 777 logs/”

For the curious ones...

In Leyman’s terms, docker is used when managing individual containers and docker-compose can be used to manage multi-container applications. It also moves many of the options you would enter on the docker run into the docker-compose.yml file for easier reuse. It works as a front end "script" on top of the same docker API used by docker. You can do everything docker-compose does with docker commands and a lot of shell scripting.

Before running our multi-container docker applications, docker-compose.yml must be configured. With that file, we define services that will be run on docker-compose up.

The first attribute of docker-compose.yml is version, which is the compose file format version. For the most recent version of file format and all configuration options click here.

Second attribute is services and all attributes one level bellow services denote containers used in our multi-container application. These are postgres, scheduler and webserver. Each container has image attribute which points to base image used for that service.

For each service, we define environment variables used inside service containers. For postgres it is defined by environment attribute, but for scheduler and webserver it is defined by .env file. Because .env is an external file we must point to it with env_file attribute.

By opening .env file we can see two variables defined. One defines executor which will be used and the other denotes connection string. Each connection string must be defined in the following manner:

dialect+driver://username:password@host:port/database

Dialect names include the identifying name of the SQLAlchemy dialect, a name such as sqlite, mysql, postgresql, oracle, or mssql. Driver is the name of the DBAPI to be used to connect to the database using all lowercase letters. In our case, connection string is defined by:

postgresql+psycopg2://airflow:airflow@postgres/airflow

Omitting port after host part denotes that we will be using default postgres port defined in its own Dockerfile.

Every service can define command which will be run inside Docker container. If one service needs to execute multiple commands it can be done by defining an optional .sh file and pointing to it with entrypoint attribute. In our case we have entrypoint.sh inside the scripts folder which once executed, runs airflow initdb and airflow webserver. Both are mandatory for airflow to run properly.

Defining depends_on attribute, we can express dependency between services. In our example, webserver starts only if both scheduler and postgres have started, also the scheduler only starts after postgres have started.

In case our container crashes, we can restart it by restart_policy. The restart_policy configures if and how to restart containers when they exit. Additional options are condition, delay, max_attempts, and window.

Once service is running, it is being served on containers defined port. To access that service we need to expose the containers port to the host's port. That is being done by ports attribute. In our case, we are exposing port 8080 of the container to TCP port 8080 on 127.0.0.1 (localhost) of the host machine. Left side of : defines host machines port and the right-hand side defines containers port.

Lastly, the volumes attribute defines shared volumes (directories) between host file system and docker container. Because airflows default working directory is /opt/airflow/ we need to point our designated volumes from the root folder to the airflow containers working directory. Such is done by the following command:

#general case for airflow
- ./<our-root-subdir>:/opt/airflow/<our-root-subdir>
#our case
- ./dags:/opt/airflow/dags
- ./logs:/opt/airflow/logs
- ./scripts:/opt/airflow/scripts
           ...

This way, when the scheduler or webserver writes logs to its logs directory we can access it from our file system within the logs directory. When we add a new dag to the dags folder it will automatically be added in the containers dag bag and so on.

Originally published by Ivan Rezic at Towardsdatascience

#docker #how-to #apache-airflow #docker-compose #postgresql

August Murray

1615008840

Top 24 Docker Commands Explained with Examples

In my previous blog post, I have explained in detail how you can Install Docker and Docker-compose on Ubuntu

In this guide, I have explained the Top 24 Docker Commands with examples.

Make sure you have sudo or root privileges to the system.

Docker Commands

The command to check the version of Docker installed.
To look/search for available docker images from the Docker registry.
To pull docker images from the Docker registry.
Listing all the docker images
Creating / Running docker container from Docker image.
To list the actively running docker containers.
To list all the docker containers
To stop a Container
To start a Container
To restart a Docker container
To login to running Docker container
To delete the stopped Docker containers
To delete Docker images from the Local system
To check logs of a running Docker container
Killing docker containers
Log in to Docker Hub registry (hub.docker.com)
Removing docker hub registry login from the system.
Check active resource usage by each containers
Rename a Docker container
To display system wide information of Docker
Inspecting a Docker container
Building docker images from Docker file
Creating new docker images from a Container
Pushing Docker images from Local to Docker registry.

#docker #docker-command #containers #docker-compose #docker-image

InfluxDB Service Configuration for Docker Compose

Service

What is GEEK

Buddha Community

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

Docker Explained: Docker Architecture | Docker Registries

InfluxDB Service Configuration for Docker Compose

Service

Apache/Airflow and PostgreSQL with Docker and Docker Compose

For those in hurry…

Top 24 Docker Commands Explained with Examples

Docker Commands

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