Joseph  Norton

Joseph Norton

1575657003

How to deploy the TICK stack as a Docker App?

Docker Application eases the packaging and the distribution of a Docker Compose application. The TICK stack – Telegraf, InfluxDB, Chronograf, and Kapacitor – is a good candidate to illustrate how this actually works. In this blog, I’ll show you how to deploy the TICK stack as a Docker App.

About the TICK Stack

This application stack is mainly used to handle time-series data. That makes it a great choice for IoT projects, where devices send data (temperature, weather indicators, water level, etc.) on a regular basis.

Its name comes from its components:

– Telegraf

– InfluxDB

– Chronograf

– Kapacitor

The schema below illustrates the overall architecture, and outlines the role of each component.

Data are sent to Telegraph and stored in an InfluxDB database. Chronograf can query the database through a web interface. Kapacitor can process, monitor, and raise alerts based on the data.

Defining the Application in a Compose File

The tick.yml file below defines the four components of the stack and the way they communicate with each other:

version: '3.7'
services:
  telegraf:
    image: telegraf
    configs:
    - source: telegraf-conf
      target: /etc/telegraf/telegraf.conf
    ports:
    - 8186:8186
  influxdb:
    image: influxdb
  chronograf:
    image: chronograf
    ports:
    - 8888:8888
    command: ["chronograf", "--influxdb-url=http://influxdb:8086"]
  kapacitor:
    image: kapacitor
    environment:
    - KAPACITOR_INFLUXDB_0_URLS_0=http://influxdb:8086
configs:
  telegraf-conf:
    file: ./telegraf.conf

Telegraf’s configuration is provided through a Docker Config object, created out of the following telegraf.conf file:

[agent]
  interval = "5s"
  round_interval = true
  metric_batch_size = 1000
  metric_buffer_limit = 10000
  collection_jitter = "0s"
  flush_interval = "5s"
  flush_jitter = "0s"
  precision = ""
  debug = false
  quiet = false
  logfile = ""
  hostname = "$HOSTNAME"
  omit_hostname = false
[[outputs.influxdb]]
  urls = ["http://influxdb:8086"]
  database = "test"
  username = ""
  password = ""
  retention_policy = ""
  write_consistency = "any"
  timeout = "5s"
[[inputs.http_listener]]
  service_address = ":8186"
[cpu]
  # Whether to report per-cpu stats or not
  percpu = true
  # Whether to report total system cpu stats or not
  totalcpu = true

This configuration:

  • Defines an agent that gathers host CPU metrics on a regular basis.
  • Defines an additional input method allowing Telegraf to receive data over HTTP.
  • Specifies the name of the database the data collected/received will be stored.

Deploying the application from Docker Desktop

Now we will deploy the application using Swarm first, and then using Kubernetes to illustrate some of the differences.

Using Swarm to Deploy the TICK Stack

First we setup a local Swarm using the following command:

$ docker swarm init

Then we deploy the TICK stack as a Docker Stack:

$ docker stack deploy tick -c tick.yaml
Creating network tick_default
Creating config tick_telegraf-conf
Creating service tick_telegraf
Creating service tick_influxdb
Creating service tick_chronograf
Creating service tick_kapacitor

This creates:

  • A network for communication between the application containers
  • A Config object containing the Telegraf configuration we defined in telegraf.conf
  • The 4 services composing the TICK stack

It only takes a couple of seconds before the application is up and running. Now we can verify the status of each service.

 docker service ls
ID                  NAME                MODE                REPLICAS            IMAGE               PORTS
74zkf54ruztg        tick_chronograf     replicated          1/1                 chronograf:latest   *:8888->8888/tcp
y97hcx3yyjx6        tick_influxdb       replicated          1/1                 influxdb:latest
fm4uckqlvhvt        tick_kapacitor      replicated          1/1                 kapacitor:latest
12zl0sa678xh        tick_telegraf       replicated          1/1                 telegraf:latest     *:8186->8186/tcp

Only Telegraf and Chronograf are exposed to the outside world:

  • Telegraf is used to ingest data through port 8186
  • Chronograf is used to visualize the data and is available through a web interface on local port 8888

To query data from the Chronograf interface, we first need to send some data to Telegraf.

Sending Test data

First we will use the lucj/genx Docker image to generate data following a cosine distribution (a couple of other simple distributions are available).

$ docker run lucj/genx
Usage of /genx:
 -duration string
      duration of the generation (default “1d”)
 -first float
      first value for linear type
 -last float
      last value for linear type (default 1)
 -max float
       max value for cos type (default 25)
 -min float
       min value for cos type (default 10)
 -period string
       period for cos type (default “1d”)
 -step string
       step / sampling period (default “1h”)
 -type string
       type of curve (default “cos”)

We will generate three days of data, with a one day period, min/max values of 10/25 and a sampling step of one hour; that will be enough for our tests.

$ docker run lucj/genx:0.1 -type cos -duration 3d -min 10 -max 25 -step 1h > /tmp/data

We then send the data to the Telegraf HTTP endpoint with the following commands:

PORT=8186
endpoint="http://localhost:$PORT/write"
cat /tmp/data | while read line; do
  ts="$(echo $line | cut -d' ' -f1)000000000"
  value=$(echo $line | cut -d' ' -f2)
  curl -i -XPOST $endpoint --data-binary "temp value=${value} ${ts}"
done

Next, from the Explore tab in the Chronograf web interface we can visualize the data using the following query:

select "value" from "test"."autogen"."temp"

We will see a neat cosine distribution:

With just a couple of commands, we have deployed the TICK stack on a Swarm cluster, sent time series data and visualized it.

Finally, we remove the stack:

$ docker stack rm tick
Removing service tick_chronograf
Removing service tick_influxdb
Removing service tick_kapacitor
Removing service tick_telegraf
Removing config tick_telegraf-conf
Removing network tick_default

We have shown how to deploy the application stack with Docker Swarm. Now we will deploy it with Kubernetes.

Using Kubernetes to Deploy the TICK Stack

From Docker Desktop, deploying the same application on a Kubernetes cluster is also a simple process.

Activate Kubernetes from Docker Desktop

First, activate Kubernetes from the Docker Desktop settings:

A local Kubernetes cluster starts quickly and is accessible right from our local environment.

When the Kubernetes cluster is created, a configuration file (also known as kubeconfig) is created locally (usually in ~/.kube/config), or used to enrich this file if it already exists. This configuration file contains all the information needed to communicate with the API Server securely:

  • The cluster’s CA
  • The API Server endpoint
  • The default user’s certificate and private key

Creating a new Docker context

Docker 19.03 introduced the context object. It allows you to quickly switch the CLI configuration to connect with different clusters. A single context exists by default as shown below:

$ docker context list
NAME                DESCRIPTION                               DOCKER ENDPOINT               KUBERNETES ENDPOINT                           ORCHESTRATOR
default *           Current DOCKER_HOST based configuration   unix:///var/run/docker.sock   https://kubernetes.docker.internal:6443 (default)   swarm

Note: as we can see from the ORCHESTRATOR column, this context can only be used to deploy workload on the local Swarm.

We will now create a new Docker context dedicated to run Kubernetes workloads. This can be done with the following command:

$ docker context create k8s-demo \
  --default-stack-orchestrator=kubernetes \
  --kubernetes config-file=$HOME/.kube/config \
  --description "Local k8s from Docker Desktop" \
  --docker host=unix:///var/run/docker.sock

Next, we verify that both contexts are now available:

$ docker context list
NAME                DESCRIPTION                               DOCKER ENDPOINT               KUBERNETES ENDPOINT                           ORCHESTRATOR
default *           Current DOCKER_HOST based configuration   unix:///var/run/docker.sock   https://kubernetes.docker.internal:6443 (default)   swarm
k8s-demo            Local k8s from Docker Desktop             unix:///var/run/docker.sock   https://kubernetes.docker.internal:6443 (default)   kubernetes

Note: we could use a single context where both orchestrators are defined. In that case, the deployment would be done on Swarm and Kubernetes at the same time.

Next, we switch on the k8s-demo context:

$ docker context use k8s-demo
k8s-demo
Current context is now "k8s-demo"

Then we deploy the application in the same way we did before, but this time it will run on Kubernetes instead of Swarm.

$ docker stack deploy tick -c tick.yaml
Waiting for the stack to be stable and running...
chronograf: Ready [pod status: 1/1 ready, 0/1 pending, 0/1 failed]
influxdb: Ready [pod status: 1/1 ready, 0/1 pending, 0/1 failed]
kapacitor: Ready [pod status: 1/1 ready, 0/1 pending, 0/1 failed]
telegraf: Ready [pod status: 1/1 ready, 0/1 pending, 0/1 failed]

Stack tick is stable and running

Stack tick is stable and running

Using the usual kubectl binary, we can verify all the Kubernetes resources have been created:

$ kubectl get deploy,po,svc
NAME                               READY   UP-TO-DATE   AVAILABLE   AGE
deployment.extensions/chronograf   1/1     1            1           2m50s
deployment.extensions/influxdb     1/1     1            1           2m50s
deployment.extensions/kapacitor    1/1     1            1           2m49s
deployment.extensions/telegraf     1/1     1            1           2m49s

NAME                             READY   STATUS    RESTARTS   AGE
pod/chronograf-c55797884-mp8gc   1/1     Running   0          2m50s
pod/influxdb-67c574845d-z6846    1/1     Running   0          2m50s
pod/kapacitor-57f6787666-t8j6l   1/1     Running   0          2m49s
pod/telegraf-6b8648884c-lq9t5    1/1     Running   0          2m49s

NAME                           TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
service/chronograf             ClusterIP      None            <none>        55555/TCP        2m49s
service/chronograf-published   LoadBalancer   10.105.63.34    <pending>     8888:32163/TCP   2m49s
service/influxdb               ClusterIP      None            <none>        55555/TCP        2m49s
service/kapacitor              ClusterIP      None            <none>        55555/TCP        2m49s
service/kubernetes             ClusterIP      10.96.0.1       <none>        443/TCP          30h
service/telegraf               ClusterIP      None            <none>        55555/TCP        2m49s
service/telegraf-published     LoadBalancer   10.107.223.80   <pending>     8186:32460/TCP   2m49s

We can generate some dummy data and visualize them using Chronograf following the same process we did above for Swarm (I only show the result here as the process is the same):

Finally we remove the stack:

$ docker stack rm tick
Removing stack: tick

Note: we used the same command to remove the stack from Kubernetes or Swarm, but notice the output is not the same as each orchestrator handles different resources / objects.

Defining the TICK stack as a DockerApp

We followed simple steps to deploy the application using both Swarm and Kubernetes. Now we’ll define it as a Docker Application to make it more portable, and see how it eases the deployment process.

Docker App is shipped with Docker 19.03+ and can be used once the experimental flag is enabled for the CLI. This can be done in several ways:

  • modifying the config.json file (usually in the $HOME/.docker folder)
 {
      "experimental": "enabled"
}
  • setting the DOCKER_CLI_EXPERIMENTAL environment variable
export DOCKER_CLI_EXPERIMENTAL=enabled

Once this is done, we can check that Docker App is enabled:

$ docker app version
Version:               v0.8.0
Git commit:            7eea32b7
Built:                 Tue Jun 11 20:53:26 2019
OS/Arch:               darwin/amd64
Experimental:          off
Renderers:             none
Invocation Base Image: docker/cnab-app-base:v0.8.0

Note: version 0.8 is currently the last version

Note: the Docker App command is experimental, which means that the feature is subject to change before being ready for production. The user experience will be updated in the next release.

Available commands in Docker App

Several commands are available to manage the lifecycle of a Docker Application, as we can see below. We will illustrate some of them later in this article.

$ docker app

Usage:	docker app COMMAND

A tool to build and manage Docker Applications.

Commands:
  bundle      Create a CNAB invocation image and `bundle.json` for the application
  completion  Generates completion scripts for the specified shell (bash or zsh)
  init        Initialize Docker Application definition
  inspect     Shows metadata, parameters and a summary of the Compose file for a given application
  install     Install an application
  list        List the installations and their last known installation result
  merge       Merge a directory format Docker Application definition into a single file
  pull        Pull an application package from a registry
  push        Push an application package to a registry
  render      Render the Compose file for an Application Package
  split       Split a single-file Docker Application definition into the directory format
  status      Get the installation status of an application
  uninstall   Uninstall an application
  upgrade     Upgrade an installed application
  validate    Checks the rendered application is syntactically correct
  version     Print version information

Run 'docker app COMMAND --help' for more information on a command.

Creating a Docker Application Package for the TICK stack

We start with the folder which contains the Docker Compose file describing the application (tick.yml) and the Telegraf configuration file (telegraf.conf):

$ tree .
.
├── telegraf.conf
└── tick.yml

Next we create the Docker Application, named tick:

$ docker app init tick --compose-file tick.yml --description "tick stack"
Created "tick.dockerapp"

This creates the folder tick.dockerapp, and three additional files:

$ tree .
.
├── telegraf.conf
├── tick.dockerapp
│   ├── docker-compose.yml
│   ├── metadata.yml
│   └── parameters.yml
└── tick.yml

1 directory, 5 files

docker-compose.yml is the copy of the tick.yml file- metadata.yml defines metadata and additional parameters

$ cat tick.dockerapp/metadata.yml
# Version of the application
version: 0.1.0
# Name of the application
name: tick
# A short description of the application
description: tick stack
# List of application maintainers with name and email for each
maintainers:
  - name: luc
    email:

parameters.yml defines the default parameters used for the application (more on this in a bit). This file is empty by default.

Note: when initializing the Docker App, it’s possible to use the -s flag. This creates a single file with the content of the three files above instead of a folder / files hierarchy.

As the application uses the telegraf.conf file, we need to copy it into tick.dockerapp folder.

Environment settings

As we mentioned above, the purpose of the parameters.yml file is to provide default values for the application. Those values will replace some placeholders we will define in the application’s compose file.

To illustrate this, we will consider a dev and a prod environments and assume those two only differ when it comes to the port exposed by the application to the outside world:

– Telegraf listens on port 8000 in dev and 9000 in prod

– Chronograf listens on port 8001 in dev and 9001 in prod

Note: In a real world application, differences between dev and prod would not be limited to a port number. The current example is over-simplified to make it easier to grasp the main concepts.

First, we create a parameter file for each environment:

parameters.yml defines some default ports for both Telegraf and Chronograf services

// parameters.yml
ports:
  telegraf: 8186
  chronograf: 8888

dev.yml specifies values for the development environment

// dev.yml
ports:
  telegraf: 8000
  chronograf: 8001

prod.yml specifies values for the production environment

// prod.yml
ports:
  telegraf: 9000
  chronograf: 9001

Next we modify the docker-compose.yml file to add some placeholders:

$ cat tick.dockerapp/docker-compose.yml
version: '3.7'
services:
  telegraf:
    image: telegraf
    configs:
    — source: telegraf-conf
      target: /etc/telegraf/telegraf.conf
    ports:
    — ${ports.telegraf}:8186
  influxdb:
    image: influxdb
  chronograf:
    image: chronograf
    ports:
    — ${ports.chronograf}:8888
    command: ["chronograf", "--influxdb-url=http://influxdb:8086"]
  kapacitor:
    image: kapacitor
    environment:
    — KAPACITOR_INFLUXDB_0_URLS_0=http://influxdb:8086
configs:
  telegraf-conf:
    file: ./telegraf.conf

As we can see in the changes above, the way to access the port for Telegraf is to use the ports.telegraf notation. The same approach is used for the Chronograf port.

The Docker App’s render command generates the Docker Compose file, substituting the variables ${ports.XXX} with the content of the settings file specified. The default parameters.yml is used if none are specified. As we can see below, the Telegraf port is now 8186, and the Chronograf one is 8888.

$ docker app render tick.dockerapp/
version: "3.7"
services:
  chronograf:
    command:
    - chronograf
    - --influxdb-url=http://influxdb:8086
    image: chronograf
    ports:
    - mode: ingress
      target: 8888
      published: 8888
      protocol: tcp
  influxdb:
    image: influxdb
  kapacitor:
    environment:
      KAPACITOR_INFLUXDB_0_URLS_0: http://influxdb:8086
    image: kapacitor
  telegraf:
    configs:
    - source: telegraf-conf
      target: /etc/telegraf/telegraf.conf
    image: telegraf
    ports:
    - mode: ingress
      target: 8186
      published: 8186
      protocol: tcp
configs:
  telegraf-conf:
    file: telegraf.conf

If we specify a parameters file in the render command, the values within that file are used. As we can see in the following example which uses dev.yml during the rendering, Telegraf is published on port 8000 and Chronograf on port 8001 (values specified in dev.yml):

$ docker app render tick.dockerapp --parameters-file tick.dockerapp/dev.yml
version: "3.7"
services:
  chronograf:
    command:
    - chronograf
    - --influxdb-url=http://influxdb:8086
    image: chronograf
    ports:
    - mode: ingress
      target: 8888
      published: 8001
      protocol: tcp
  influxdb:
    image: influxdb
  kapacitor:
    environment:
      KAPACITOR_INFLUXDB_0_URLS_0: http://influxdb:8086
    image: kapacitor
  telegraf:
    configs:
    - source: telegraf-conf
      target: /etc/telegraf/telegraf.conf
    image: telegraf
    ports:
    - mode: ingress
      target: 8186
      published: 8000
      protocol: tcp
configs:
  telegraf-conf:
    file: telegraf.conf

Inspecting the application

The inspect command provides all the information related to the application:

– Its metadata

– The services involved

– The default parameter values- The files the application depends on (telegraf.conf in this example)

$ docker app inspect tick
tick 0.1.0

Maintained by: luc

tick stack

Services (4) Replicas Ports Image
------------ -------- ----- -----
chronograf   1        8888  chronograf
influxdb     1              influxdb
kapacitor    1              kapacitor
telegraf     1        8186  telegraf

Parameters (2)   Value
--------------   -----
ports.chronograf 8888
ports.telegraf   8186

Attachments (3) Size
--------------- ----
dev.yml         43B
prod.yml        43B
telegraf.conf   657B

Deploying the Docker App on a Swarm Cluster

First, we go back to the default context which references a Swarm cluster.

$ docker context use default

Next, we deploy the application as a Docker App:

$ docker app install tick.dockerapp --name tick --parameters-file tick.dockerapp/prod.yml
Creating network tick_default
Creating config tick_telegraf-conf
Creating service tick_telegraf
Creating service tick_influxdb
Creating service tick_chronograf
Creating service tick_kapacitor
Application "tick" installed on context "default"

Then we list the deployed application to make sure the one created above is there:

$ docker app list
INSTALLATION APPLICATION  LAST ACTION RESULT  CREATED   MODIFIED  REFERENCE
tick         tick (0.1.0) install     success 4 minutes 3 minutes

Next we list the services running on the Swarm cluster. We can see the values from the prod.yml parameters file have been taken into account (as the exposed ports are 9000 and 9001 for Telegraf and Chronograf respectively).

$ docker service ls
ID               NAME             MODE           REPLICAS    IMAGE               PORTS
75onunrvoxgt     tick_chronograf  replicated     1/1         chronograf:latest   *:9001->8888/tcp
vj1ttws2mw1u     tick_influxdb    replicated     1/1         influxdb:latest
q4brz1i45cai     tick_kapacitor   replicated     1/1         kapacitor:latest
i6kvr37ycnn5     tick_telegraf    replicated     1/1         telegraf:latest     *:9000->8186/tcp

Pushing the application to Docker Hub

A Docker application can be distributed through the Docker Hub via a simple push:

$ docker app push tick --tag lucj/tick:0.1.0
...
Successfully pushed bundle to docker.io/lucj/tick:0.1.0\. Digest is sha256:7a71d2bfb5588be0cb74cd76cc46575b58c433da1fa05b4eeccd5288b4b75bac.

It then appears next to the Docker images on the account it was pushed to:

The application is now ready to be used by anyone; it just needs to be pulled from the Docker Hub:

$ docker app pull lucj/tick:0.1.0

Before we move to the next part, we will remove the application we deployed on the Swarm cluster:

$ docker app uninstall tick
Removing service tick_chronograf
Removing service tick_influxdb
Removing service tick_kapacitor
Removing service tick_telegraf
Removing config tick_telegraf-conf
Removing network tick_default
Application "tick" uninstalled on context "default"

Deploying the Docker App on Kubernetes

We saw how easy it is to deploy a Docker App on Swarm. We will now deploy it on Kubernetes, and we’ll see it’s just as easy.

First, we set the Docker context to use Kubernetes as the orchestrator.

$ docker context use k8s-demo
k8s-demo
Current context is now "k8s-demo"

Next, we install the application with the exact same command we used to deploy it on Swarm:

$ docker app install tick.dockerapp --name tick --parameters-file tick.dockerapp/prod.yml
Waiting for the stack to be stable and running...
influxdb: Pending
chronograf: Pending
kapacitor: Pending
telegraf: Pending
telegraf: Ready
kapacitor: Ready
chronograf: Ready
influxdb: Ready

Stack tick is stable and running

Application "tick" installed on context "k8s-demo"

Using kubectl, we list the resources to make sure everything was created correctly:

$ kubectl get deploy,po,svc
NAME                               READY   UP-TO-DATE   AVAILABLE   AGE
deployment.extensions/chronograf   1/1     1            1           26s
deployment.extensions/influxdb     1/1     1            1           26s
deployment.extensions/kapacitor    1/1     1            1           26s
deployment.extensions/telegraf     1/1     1            1           26s

NAME                             READY   STATUS    RESTARTS   AGE
pod/chronograf-c55797884-b7rcd   1/1     Running   0          26s
pod/influxdb-67c574845d-bcr8m    1/1     Running   0          26s
pod/kapacitor-57f6787666-82b7l   1/1     Running   0          26s
pod/telegraf-6b8648884c-xcmmx    1/1     Running   0          26s

NAME                           TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
service/chronograf             ClusterIP      None            <none>        55555/TCP        25s
service/chronograf-published   LoadBalancer   10.104.26.162   <pending>     9001:31319/TCP   25s
service/influxdb               ClusterIP      None            <none>        55555/TCP        26s
service/kapacitor              ClusterIP      None            <none>        55555/TCP        26s
service/kubernetes             ClusterIP      10.96.0.1       <none>        443/TCP          2d4h
service/telegraf               ClusterIP      None            <none>        55555/TCP        26s
service/telegraf-published     LoadBalancer   10.108.195.24   <pending>     9000:30684/TCP   25s

Note: The deployment on Kubernetes only works on Docker Desktop or Docker Enterprise, which run the server side controller needed to handle the stack resource.

Summary

I hope this article provides some insights on the Docker Application. The project is still quite young so breaking changes may occur before it reaches 1.0.0, but one thing that’s promising – it lets us deploy to Kubernetes without knowing much of anything about Kubernetes!

#Docker #DevOps

What is GEEK

Buddha Community

How to deploy the TICK stack as a Docker App?
Carmen  Grimes

Carmen Grimes

1595494844

How to start an electric scooter facility/fleet in a university campus/IT park

Are you leading an organization that has a large campus, e.g., a large university? You are probably thinking of introducing an electric scooter/bicycle fleet on the campus, and why wouldn’t you?

Introducing micro-mobility in your campus with the help of such a fleet would help the people on the campus significantly. People would save money since they don’t need to use a car for a short distance. Your campus will see a drastic reduction in congestion, moreover, its carbon footprint will reduce.

Micro-mobility is relatively new though and you would need help. You would need to select an appropriate fleet of vehicles. The people on your campus would need to find electric scooters or electric bikes for commuting, and you need to provide a solution for this.

To be more specific, you need a short-term electric bike rental app. With such an app, you will be able to easily offer micro-mobility to the people on the campus. We at Devathon have built Autorent exactly for this.

What does Autorent do and how can it help you? How does it enable you to introduce micro-mobility on your campus? We explain these in this article, however, we will touch upon a few basics first.

Micro-mobility: What it is

micro-mobility

You are probably thinking about micro-mobility relatively recently, aren’t you? A few relevant insights about it could help you to better appreciate its importance.

Micro-mobility is a new trend in transportation, and it uses vehicles that are considerably smaller than cars. Electric scooters (e-scooters) and electric bikes (e-bikes) are the most popular forms of micro-mobility, however, there are also e-unicycles and e-skateboards.

You might have already seen e-scooters, which are kick scooters that come with a motor. Thanks to its motor, an e-scooter can achieve a speed of up to 20 km/h. On the other hand, e-bikes are popular in China and Japan, and they come with a motor, and you can reach a speed of 40 km/h.

You obviously can’t use these vehicles for very long commutes, however, what if you need to travel a short distance? Even if you have a reasonable public transport facility in the city, it might not cover the route you need to take. Take the example of a large university campus. Such a campus is often at a considerable distance from the central business district of the city where it’s located. While public transport facilities may serve the central business district, they wouldn’t serve this large campus. Currently, many people drive their cars even for short distances.

As you know, that brings its own set of challenges. Vehicular traffic adds significantly to pollution, moreover, finding a parking spot can be hard in crowded urban districts.

Well, you can reduce your carbon footprint if you use an electric car. However, electric cars are still new, and many countries are still building the necessary infrastructure for them. Your large campus might not have the necessary infrastructure for them either. Presently, electric cars don’t represent a viable option in most geographies.

As a result, you need to buy and maintain a car even if your commute is short. In addition to dealing with parking problems, you need to spend significantly on your car.

All of these factors have combined to make people sit up and think seriously about cars. Many people are now seriously considering whether a car is really the best option even if they have to commute only a short distance.

This is where micro-mobility enters the picture. When you commute a short distance regularly, e-scooters or e-bikes are viable options. You limit your carbon footprints and you cut costs!

Businesses have seen this shift in thinking, and e-scooter companies like Lime and Bird have entered this field in a big way. They let you rent e-scooters by the minute. On the other hand, start-ups like Jump and Lyft have entered the e-bike market.

Think of your campus now! The people there might need to travel short distances within the campus, and e-scooters can really help them.

How micro-mobility can benefit you

benefits-micromobility

What advantages can you get from micro-mobility? Let’s take a deeper look into this question.

Micro-mobility can offer several advantages to the people on your campus, e.g.:

  • Affordability: Shared e-scooters are cheaper than other mass transportation options. Remember that the people on your campus will use them on a shared basis, and they will pay for their short commutes only. Well, depending on your operating model, you might even let them use shared e-scooters or e-bikes for free!
  • Convenience: Users don’t need to worry about finding parking spots for shared e-scooters since these are small. They can easily travel from point A to point B on your campus with the help of these e-scooters.
  • Environmentally sustainable: Shared e-scooters reduce the carbon footprint, moreover, they decongest the roads. Statistics from the pilot programs in cities like Portland and Denver showimpressive gains around this key aspect.
  • Safety: This one’s obvious, isn’t it? When people on your campus use small e-scooters or e-bikes instead of cars, the problem of overspeeding will disappear. you will see fewer accidents.

#android app #autorent #ios app #mobile app development #app like bird #app like bounce #app like lime #autorent #bird scooter business model #bird scooter rental #bird scooter rental cost #bird scooter rental price #clone app like bird #clone app like bounce #clone app like lime #electric rental scooters #electric scooter company #electric scooter rental business #how do you start a moped #how to start a moped #how to start a scooter rental business #how to start an electric company #how to start electric scooterrental business #lime scooter business model #scooter franchise #scooter rental business #scooter rental business for sale #scooter rental business insurance #scooters franchise cost #white label app like bird #white label app like bounce #white label app like lime

Carmen  Grimes

Carmen Grimes

1595491178

Best Electric Bikes and Scooters for Rental Business or Campus Facility

The electric scooter revolution has caught on super-fast taking many cities across the globe by storm. eScooters, a renovated version of old-school scooters now turned into electric vehicles are an environmentally friendly solution to current on-demand commute problems. They work on engines, like cars, enabling short traveling distances without hassle. The result is that these groundbreaking electric machines can now provide faster transport for less — cheaper than Uber and faster than Metro.

Since they are durable, fast, easy to operate and maintain, and are more convenient to park compared to four-wheelers, the eScooters trend has and continues to spike interest as a promising growth area. Several companies and universities are increasingly setting up shop to provide eScooter services realizing a would-be profitable business model and a ready customer base that is university students or residents in need of faster and cheap travel going about their business in school, town, and other surrounding areas.

Electric Scooters Trends and Statistics

In many countries including the U.S., Canada, Mexico, U.K., Germany, France, China, Japan, India, Brazil and Mexico and more, a growing number of eScooter users both locals and tourists can now be seen effortlessly passing lines of drivers stuck in the endless and unmoving traffic.

A recent report by McKinsey revealed that the E-Scooter industry will be worth― $200 billion to $300 billion in the United States, $100 billion to $150 billion in Europe, and $30 billion to $50 billion in China in 2030. The e-Scooter revenue model will also spike and is projected to rise by more than 20% amounting to approximately $5 billion.

And, with a necessity to move people away from high carbon prints, traffic and congestion issues brought about by car-centric transport systems in cities, more and more city planners are developing more bike/scooter lanes and adopting zero-emission plans. This is the force behind the booming electric scooter market and the numbers will only go higher and higher.

Companies that have taken advantage of the growing eScooter trend develop an appthat allows them to provide efficient eScooter services. Such an app enables them to be able to locate bike pick-up and drop points through fully integrated google maps.

List of Best Electric Bikes for Rental Business or Campus Facility 2020:

It’s clear that e scooters will increasingly become more common and the e-scooter business model will continue to grab the attention of manufacturers, investors, entrepreneurs. All this should go ahead with a quest to know what are some of the best electric bikes in the market especially for anyone who would want to get started in the electric bikes/scooters rental business.

We have done a comprehensive list of the best electric bikes! Each bike has been reviewed in depth and includes a full list of specs and a photo.

Billy eBike

mobile-best-electric-bikes-scooters https://www.kickstarter.com/projects/enkicycles/billy-were-redefining-joyrides

To start us off is the Billy eBike, a powerful go-anywhere urban electric bike that’s specially designed to offer an exciting ride like no other whether you want to ride to the grocery store, cafe, work or school. The Billy eBike comes in 4 color options – Billy Blue, Polished aluminium, Artic white, and Stealth black.

Price: $2490

Available countries

Available in the USA, Europe, Asia, South Africa and Australia.This item ships from the USA. Buyers are therefore responsible for any taxes and/or customs duties incurred once it arrives in your country.

Features

  • Control – Ride with confidence with our ultra-wide BMX bars and a hyper-responsive twist throttle.
  • Stealth- Ride like a ninja with our Gates carbon drive that’s as smooth as butter and maintenance-free.
  • Drive – Ride further with our high torque fat bike motor, giving a better climbing performance.
  • Accelerate – Ride quicker with our 20-inch lightweight cutout rims for improved acceleration.
  • Customize – Ride your own way with 5 levels of power control. Each level determines power and speed.
  • Flickable – Ride harder with our BMX /MotoX inspired geometry and lightweight aluminum package

Specifications

  • Maximum speed: 20 mph (32 km/h)
  • Range per charge: 41 miles (66 km)
  • Maximum Power: 500W
  • Motor type: Fat Bike Motor: Bafang RM G060.500.DC
  • Load capacity: 300lbs (136kg)
  • Battery type: 13.6Ah Samsung lithium-ion,
  • Battery capacity: On/off-bike charging available
  • Weight: w/o batt. 48.5lbs (22kg), w/ batt. 54lbs (24.5kg)
  • Front Suspension: Fully adjustable air shock, preload/compression damping /lockout
  • Rear Suspension: spring, preload adjustment
  • Built-in GPS

Why Should You Buy This?

  • Riding fun and excitement
  • Better climbing ability and faster acceleration.
  • Ride with confidence
  • Billy folds for convenient storage and transportation.
  • Shorty levers connect to disc brakes ensuring you stop on a dime
  • belt drives are maintenance-free and clean (no oil or lubrication needed)

**Who Should Ride Billy? **

Both new and experienced riders

**Where to Buy? **Local distributors or ships from the USA.

Genze 200 series e-Bike

genze-best-electric-bikes-scooters https://www.genze.com/fleet/

Featuring a sleek and lightweight aluminum frame design, the 200-Series ebike takes your riding experience to greater heights. Available in both black and white this ebike comes with a connected app, which allows you to plan activities, map distances and routes while also allowing connections with fellow riders.

Price: $2099.00

Available countries

The Genze 200 series e-Bike is available at GenZe retail locations across the U.S or online via GenZe.com website. Customers from outside the US can ship the product while incurring the relevant charges.

Features

  • 2 Frame Options
  • 2 Sizes
  • Integrated/Removable Battery
  • Throttle and Pedal Assist Ride Modes
  • Integrated LCD Display
  • Connected App
  • 24 month warranty
  • GPS navigation
  • Bluetooth connectivity

Specifications

  • Maximum speed: 20 mph with throttle
  • Range per charge: 15-18 miles w/ throttle and 30-50 miles w/ pedal assist
  • Charging time: 3.5 hours
  • Motor type: Brushless Rear Hub Motor
  • Gears: Microshift Thumb Shifter
  • Battery type: Removable Samsung 36V, 9.6AH Li-Ion battery pack
  • Battery capacity: 36V and 350 Wh
  • Weight: 46 pounds
  • Derailleur: 8-speed Shimano
  • Brakes: Dual classic
  • Wheels: 26 x 20 inches
  • Frame: 16, and 18 inches
  • Operating Mode: Analog mode 5 levels of Pedal Assist Thrott­le Mode

Norco from eBikestore

norco-best-electric-bikes-scooters https://ebikestore.com/shop/norco-vlt-s2/

The Norco VLT S2 is a front suspension e-Bike with solid components alongside the reliable Bosch Performance Line Power systems that offer precise pedal assistance during any riding situation.

Price: $2,699.00

Available countries

This item is available via the various Norco bikes international distributors.

Features

  • VLT aluminum frame- for stiffness and wheel security.
  • Bosch e-bike system – for their reliability and performance.
  • E-bike components – for added durability.
  • Hydraulic disc brakes – offer riders more stopping power for safety and control at higher speeds.
  • Practical design features – to add convenience and versatility.

Specifications

  • Maximum speed: KMC X9 9spd
  • Motor type: Bosch Active Line
  • Gears: Shimano Altus RD-M2000, SGS, 9 Speed
  • Battery type: Power Pack 400
  • Battery capacity: 396Wh
  • Suspension: SR Suntour suspension fork
  • Frame: Norco VLT, Aluminum, 12x142mm TA Dropouts

Bodo EV

bodo-best-electric-bikes-scootershttp://www.bodoevs.com/bodoev/products_show.asp?product_id=13

Manufactured by Bodo Vehicle Group Limited, the Bodo EV is specially designed for strong power and extraordinary long service to facilitate super amazing rides. The Bodo Vehicle Company is a striking top in electric vehicles brand field in China and across the globe. Their Bodo EV will no doubt provide your riders with high-level riding satisfaction owing to its high-quality design, strength, breaking stability and speed.

Price: $799

Available countries

This item ships from China with buyers bearing the shipping costs and other variables prior to delivery.

Features

  • Reliable
  • Environment friendly
  • Comfortable riding
  • Fashionable
  • Economical
  • Durable – long service life
  • Braking stability
  • LED lighting technology

Specifications

  • Maximum speed: 45km/h
  • Range per charge: 50km per person
  • Charging time: 8 hours
  • Maximum Power: 3000W
  • Motor type: Brushless DC Motor
  • Load capacity: 100kg
  • Battery type: Lead-acid battery
  • Battery capacity: 60V 20AH
  • Weight: w/o battery 47kg

#android app #autorent #entrepreneurship #ios app #minimum viable product (mvp) #mobile app development #news #app like bird #app like bounce #app like lime #autorent #best electric bikes 2020 #best electric bikes for rental business #best electric kick scooters 2020 #best electric kickscooters for rental business #best electric scooters 2020 #best electric scooters for rental business #bird scooter business model #bird scooter rental #bird scooter rental cost #bird scooter rental price #clone app like bird #clone app like bounce #clone app like lime #electric rental scooters #electric scooter company #electric scooter rental business #how do you start a moped #how to start a moped #how to start a scooter rental business #how to start an electric company #how to start electric scooterrental business #lime scooter business model #scooter franchise #scooter rental business #scooter rental business for sale #scooter rental business insurance #scooters franchise cost #white label app like bird #white label app like bounce #white label app like lime

Fredy  Larson

Fredy Larson

1595059664

How long does it take to develop/build an app?

With more of us using smartphones, the popularity of mobile applications has exploded. In the digital era, the number of people looking for products and services online is growing rapidly. Smartphone owners look for mobile applications that give them quick access to companies’ products and services. As a result, mobile apps provide customers with a lot of benefits in just one device.

Likewise, companies use mobile apps to increase customer loyalty and improve their services. Mobile Developers are in high demand as companies use apps not only to create brand awareness but also to gather information. For that reason, mobile apps are used as tools to collect valuable data from customers to help companies improve their offer.

There are many types of mobile applications, each with its own advantages. For example, native apps perform better, while web apps don’t need to be customized for the platform or operating system (OS). Likewise, hybrid apps provide users with comfortable user experience. However, you may be wondering how long it takes to develop an app.

To give you an idea of how long the app development process takes, here’s a short guide.

App Idea & Research

app-idea-research

_Average time spent: two to five weeks _

This is the initial stage and a crucial step in setting the project in the right direction. In this stage, you brainstorm ideas and select the best one. Apart from that, you’ll need to do some research to see if your idea is viable. Remember that coming up with an idea is easy; the hard part is to make it a reality.

All your ideas may seem viable, but you still have to run some tests to keep it as real as possible. For that reason, when Web Developers are building a web app, they analyze the available ideas to see which one is the best match for the targeted audience.

Targeting the right audience is crucial when you are developing an app. It saves time when shaping the app in the right direction as you have a clear set of objectives. Likewise, analyzing how the app affects the market is essential. During the research process, App Developers must gather information about potential competitors and threats. This helps the app owners develop strategies to tackle difficulties that come up after the launch.

The research process can take several weeks, but it determines how successful your app can be. For that reason, you must take your time to know all the weaknesses and strengths of the competitors, possible app strategies, and targeted audience.

The outcomes of this stage are app prototypes and the minimum feasible product.

#android app #frontend #ios app #minimum viable product (mvp) #mobile app development #web development #android app development #app development #app development for ios and android #app development process #ios and android app development #ios app development #stages in app development

YuccaPrerenderBundle: Symfony2 Bundle to Use Prerender.io

Yucca/PrerenderBundle

Backbone, EmberJS, Angular and so more are your daily basis ? In case of an admin area, that's fine, but on your front office, you might encounter some SEO problems

Thanks to Prerender.io, you now can dynamically render your JavaScript pages in your server using PhantomJS.

This bundle is largely inspired by bakura10 work on zfr-prerender

Installation

Install the module by typing (or add it to your composer.json file):

$ php composer.phar require "yucca/prerender-bundle" "0.1.*@dev"

Register the bundle in app/AppKernel.php:

// app/AppKernel.php
public function registerBundles()
{
    return array(
        // ...
        new Yucca\PrerenderBundle\YuccaPrerenderBundle(),
    );
}

Enable the bundle's configuration in app/config/config.yml:

# app/config/config.yml
yucca_prerender: ~

Documentation

How it works

  1. Check to make sure we should show a prerendered page
    1. Check if the request is from a crawler (agent string)
    2. Check to make sure we aren't requesting a resource (js, css, etc...)
    3. (optional) Check to make sure the url is in the whitelist
    4. (optional) Check to make sure the url isn't in the blacklist
  2. Make a GET request to the prerender service (PhantomJS server) for the page's prerendered HTML
  3. Return that HTML to the crawler

Customization

This bundle comes with a sane default, extracted from prerender-node middleware, but you can easily customize it:

#app/config/config.yml
yucca_prerender:
    ....

Prerender URL

By default, YuccaPrerenderBundle uses the Prerender.io service deployed at http://prerender.herokuapp.com. However, you may want to deploy it on your own server. To that extent, you can customize YuccaPrerenderBundle to use your server using the following configuration:

#app/config/config.yml
yucca_prerender:
    backend_url: http://localhost:3000

With this config, here is how YuccaPrerender will proxy the "https://google.com" request:

GET http://localhost:3000/https://google.com

Crawler user-agents

YuccaPrerender decides to pre-render based on the User-Agent string to check if a request comes from a bot or not. By default, those user agents are registered: 'baiduspider', 'facebookexternalhit', 'twitterbot'. Googlebot, Yahoo, and Bingbot should not be in this list because we support escaped_fragment instead of checking user agent for those crawlers. Your site must have to understand the '#!' ajax url notation.

You can add other User-Agent string to evaluate using this sample configuration:

#app/config/config.yml
yucca_prerender:
    crawler_user_agents: ['yandex', 'msnbot']

Ignored extensions

YuccaPrerender is configured by default to ignore all the requests for resources with those extensions: .js, .css, .less, .png, .jpg, .jpeg, .gif, .pdf, .doc, .txt, .zip, .mp3, .rar, .exe, .wmv, .doc, .avi, .ppt, .mpg, .mpeg, .tif, .wav, .mov, .psd, .ai, .xls, .mp4, .m4a, .swf, .dat, .dmg, .iso, .flv, .m4v, .torrent . Those are never pre-rendered.

You can add your own extensions using this sample configuration:

#app/config/config.yml
yucca_prerender:
    ignored_extensions: ['.less', '.pdf']

Whitelist

Whitelist a single url path or multiple url paths. Compares using regex, so be specific when possible. If a whitelist is supplied, only url's containing a whitelist path will be prerendered.

Here is a sample configuration that only pre-render URLs that contains "/users/":

#app/config/config.yml
yucca_prerender:
    whitelist_urls: ['/users/*']

Note: remember to specify URL here and not Symfony2 route names.

Blacklist

Blacklist a single url path or multiple url paths. Compares using regex, so be specific when possible. If a blacklist is supplied, all url's will be pre-rendered except ones containing a blacklist part. Please note that if the referer is part of the blacklist, it won't be pre-rendered too.

Here is a sample configuration that prerender all URLs excepting the ones that contains "/users/":

#app/config/config.yml
yucca_prerender:
    blacklist_urls: ['/users/*']

Note: remember to specify URL here and not Symfony22 route names.

Testing

If you want to make sure your pages are rendering correctly:

  1. Open the Developer Tools in Chrome (Cmd + Atl + J)
  2. Click the Settings gear in the bottom right corner.
  3. Click "Overrides" on the left side of the settings panel.
  4. Check the "User Agent" checkbox.
  5. Choose "Other..." from the User Agent dropdown.
  6. Type googlebot into the input box.
  7. Refresh the page (make sure to keep the developer tools open).

Thanks

  • Thanks to bakura10 for the Zend Framework version.
  • Thanks to Romain Boyer to make me discover prerender.io
  • Thanks to the prerender team and all JS MVC developpers

Author: rjanot
Source Code: https://github.com/rjanot/YuccaPrerenderBundle 
License: MIT License

#php #symfony 

ThruwayBundle: Bundle for Building Real-time Apps in Symfony

ThruwayBundle

This a Symfony Bundle for Thruway, which is a php implementation of WAMP (Web Application Messaging Protocol).

Note: This project is still undergoing a lot of changes, so the API will change.

Quick Start with Composer

Install the Thruway Bundle

  $ composer require "voryx/thruway-bundle"

Update AppKernel.php (when using Symfony < 4)

$bundles = array(
    // ...
    new Voryx\ThruwayBundle\VoryxThruwayBundle(),
    // ...
);

Configuration

#app/config/config.yml

voryx_thruway:
    realm: 'realm1'
    url: 'ws://127.0.0.1:8081' #The url that the clients will use to connect to the router
    router:
        ip: '127.0.0.1'  # the ip that the router should start on
        port: '8080'  # public facing port.  If authentication is enabled, this port will be protected
        trusted_port: '8081' # Bypasses all authentication.  Use this for trusted clients.
#        authentication: false # true will load the AuthenticationManager
    locations:
        bundles: ["AppBundle"]
#        files:
#            - "Acme\\DemoBundle\\Controller\\DemoController"
#
# For symfony 4, this bundle will automatically scan for annotated worker files in the src/Controller folder
      

With Symfony 4 use a filename like: config/packages/voryx.yaml

If you are using the in-memory user provider, you'll need to add a thruway to the security firewall and set the in_memory_user_provider.

#app/config/security.yml

security: 
   firewalls:
        thruway:
            security: false	     

You can also tag services with thruway.resource and any annotation will get picked up

<service id="some.service" class="Acme\Bundle\SomeService">
    <tag name="thruway.resource"/>
</service>

Note: tagging a service as thruway.resource will make it public.

services:
    App\Worker\:
        resource: '../src/Worker'
        tags: ['thruway.resource']

Authentication with FOSUserBundle via WampCRA

Change the Password Encoder (tricky on existing sites) to master wamp challenge

#app/config/security.yml

security:
    ...
    encoders:
        FOS\UserBundle\Model\UserInterface:
            algorithm:            pbkdf2
            hash_algorithm:       sha256
            encode_as_base64:     true
            iterations:           1000
            key_length:           32

set voryx_thruway.user_provider to "fos_user.user_provider"

#app/config/config.yml

voryx_thruway:
    user_provider: 'fos_user.user_provider.username' #fos_user.user_provider.username_email login with email

The WAMP-CRA service is already configured, we just need to add a tag to it to have the bundle install it:

    wamp_cra_auth:
        class: Thruway\Authentication\WampCraAuthProvider
        parent: voryx.thruway.wamp.cra.auth.client
        tags:
            - { name: thruway.internal_client }

Custom Authorization Manager

You can set your own Authorization Manager in order to check if a user (identified by its authid) is allowed to publish | subscribe | call | register

Create your Authorization Manager service, extending RouterModuleClient and implementing RealmModuleInterface (see the Thruway doc for details)

// src/ACME/AppBundle/Security/MyAuthorizationManager.php


use Thruway\Event\MessageEvent;
use Thruway\Event\NewRealmEvent;
use Thruway\Module\RealmModuleInterface;
use Thruway\Module\RouterModuleClient;

class MyAuthorizationManager extends RouterModuleClient implements RealmModuleInterface
{
    /**
     * Listen for Router events.
     * Required to add the authorization module to the realm
     *
     * @return array
     */
    public static function getSubscribedEvents()
    {
        return [
            'new_realm' => ['handleNewRealm', 10]
        ];
    }

    /**
     * @param NewRealmEvent $newRealmEvent
     */
    public function handleNewRealm(NewRealmEvent $newRealmEvent)
    {
        $realm = $newRealmEvent->realm;

        if ($realm->getRealmName() === $this->getRealm()) {
            $realm->addModule($this);
        }
    }

    /**
     * @return array
     */
    public function getSubscribedRealmEvents()
    {
        return [
            'PublishMessageEvent'   => ['authorize', 100],
            'SubscribeMessageEvent' => ['authorize', 100],
            'RegisterMessageEvent'  => ['authorize', 100],
            'CallMessageEvent'      => ['authorize', 100],
        ];
    }

    /**
     * @param MessageEvent $msg
     * @return bool
     */
    public function authorize(MessageEvent $msg)
    {
        if ($msg->session->getAuthenticationDetails()->getAuthId() === 'username') {
            return true;
        }
        return false;
    }
}

Register your authorization manager service

     my_authorization_manager:
        class: ACME\AppBundle\Security\MyAuthorizationManager

Insert your service name in the voryx_thruway config

#app/config/config.yml

voryx_thruway:
    ...
        authorization: my_authorization_manager # insert the name of your custom authorizationManager
   ...

Restart the Thruway server; it will now check authorization upon publish | subscribe | call | register. Remember to catch error when you try to subscribe to a topic (or any other action) as it may now be denied and this will be returned as an error.

Usage

Register RPC

    use Voryx\ThruwayBundle\Annotation\Register;
    
    /**
     *
     * @Register("com.example.add")
     *
     */
    public function addAction($num1, $num2)
    {
        return $num1 + $num2;
    }

Call RPC

    public function call($value)
    {
        $client = $this->container->get('thruway.client');
        $client->call("com.myapp.add", [2, 3])->then(
            function ($res) {
                echo $res[0];
            }
        );
    }

Subscribe

     use Voryx\ThruwayBundle\Annotation\Subscribe;

    /**
     *
     * @Subscribe("com.example.subscribe")
     *
     */
    public function subscribe($value)
    {
        echo $value;
    }

Publish

    public function publish($value)
    {
        $client = $this->container->get('thruway.client');
        $client->publish("com.myapp.hello_pubsub", [$value]);
    }

It uses Symfony Serializer, so it can serialize and deserialize Entities

         use Voryx\ThruwayBundle\Annotation\Register;

    /**
     *
     * @Register("com.example.addrpc", serializerEnableMaxDepthChecks=true)
     *
     */
    public function addAction(Post $post)
    {
        //Do something to $post

        return $post;
    }

Start the Thruway Process

You can start the default Thruway workers (router and client workers), without any additional configuration.

$ nohup php app/console thruway:process start &

By default, the router starts on ws://127.0.0.1:8080

Workers

The Thruway bundle will start up a separate process for the router and each defined worker. If you haven't defined any workers, all of the annotated calls and subscriptions will be started within the default worker.

There are two main ways to break your application apart into multiple workers.

Use the worker property on the Register and Subscribe annotations. The following RPC will be added to the posts worker.

  use Voryx\ThruwayBundle\Annotation\Register;

  /**
  * @Register("com.example.addrpc", serializerEnableMaxDepthChecks=true, worker="posts")
  */
  public function addAction(Post $post)

Use the @Worker annotation on the class. The following annotation will create a worker called chat that can have a max of 5 instances.

  use Voryx\ThruwayBundle\Annotation\Worker;

  /**
  * @Worker("chat", maxProcesses="5")
  */
  class ChatController

If a worker is shut down with anything other than SIGTERM, it will automatically be restarted.

More Commands

To see a list of running processes (workers)

$ php app/console thruway:process status

Stop a process, i.e. default

$ php app/console thruway:process stop default

Start a process, i.e. default

$ php app/console thruway:process start default

Javascript Client

For the client, you can use AutobahnJS or any other WAMPv2 compatible client.

Here are some examples

Symfony 4 Quick Start

composer create-project symfony/skeleton my_project
cd my_project
composer require symfony/expression-language
composer require symfony/annotations-pack
composer require voryx/thruway-bundle:dev-master

Create config/packages/my_project.yml with the following config:

voryx_thruway:
    realm: 'realm1'
    url: 'ws://127.0.0.1:8081' #The url that the clients will use to connect to the router
    router:
        ip: '127.0.0.1'  # the ip that the router should start on
        port: '8080'  # public facing port.  If authentication is enabled, this port will be protected
        trusted_port: '8081' # Bypasses all authentication.  Use this for trusted clients.

Create the controller src/Controller/TestController.php

<?php
namespace App\Controller;

use Voryx\ThruwayBundle\Annotation\Register;

class TestController
{
    /**
     * @Register("com.example.add")
     */
    public function addAction($num1, $num2)
    {
        return $num1 + $num2;
    }
}

Test to see if the RPC has been configured correctly bin/console thruway:debug

 URI             Type Worker  File                                                  Method    
 com.example.add RPC  default /my_project/src/Controller/TestController.php         addAction 

For more debug info for the RPC we created: bin/console thruway:debug com.example.add

Start everything: bin/console thruway:process start

The RPC com.example.add is now available to any WAMP client connected to ws://127.0.0.1:8081 on realm1.

Author: Voryx
Source Code: https://github.com/voryx/ThruwayBundle 
License: 

#php #symfony