This document briefly describes developing and installation principles of port activity application software component. Further in depth information of installation and software configurations are not in scope of this document.
As described in architecture document software is split into following components:
Minimum setup to run application application is:
Minimum setup to get application running for web and mobile is:
Common setup to running application is
If your data sources can post you directly timestamps then in best case you don’t need any agents that poll data. To simulate getting data into system you can do test post timestamp manually yourself:
curl 'http://localhost:8000/agent/rest/timestamps' \
-XPOST \
-H 'Accept: application/json, text/plain, */*' \
-H 'Content-Type: application/json;charset=utf-8' \
-H 'Authorization: ApiKey xxx' \
-H 'Connection: keep-alive' \
--data-binary '{"imo": "9295347", "vessel_name": "ADVANTAGE PARK", "time_type": "Estimated", "state": "Departure_Vessel_Berth", "time": "2020-10-16T01:00:00.867Z", "payload": {"from_port":"FIHKI", "to_port": "SEGVX", "next_port":"FIRAU"}}'
Prior to porting you need to:
For every component follow repository readme.md
to setup your environment. In most cases you need to
yarn install
or make install
)docker-composer up
or make run
)Development environment services are running on localhost and some are running in containers. Eg. default setup is that API is running on http://localhost:8000
and web UI is running on http://localhost:3000
. Timestamp clustering agent is running on http://localhost:5000
.
Referring from another service running in a container could be tricky since all services are not started with single docker-compose command. Eg. you might need to refer from api to timestamp clustering agent as http://host.docker.internal:5000/
with mac. On windows and linux environments you need to use localhost or IP directly.
Most common and convenient way to deploy components is
You can orchestrate your deployment with Kubernetes on your cloud provider. You can even take one step further and orchestrate your Kubernetes cluster with Rancher to avoid as much as possible vendor lock down to a specific cloud provider.
First deployments have been done with Rancher and Google Kubernetes Engine. Most repositories have pipeline scripts that could be used for automate build and deployment process. See .rancher-pipeline.yaml
and deployment.yml
files on each repository.
Follow instructions in https://github.com/port-activity/api
When API is up and running it provides backbone for application to run. On development is running on certain port yet on real deployment it should be available with DNS and forwarded with proxy from an url:
UIs and other services must be then configured to use this URL.
API has several dependencies, eg. postgresql and redis, that must be hosted separately. Redis can be non-persistent (yet you might want to run it with persistent data) and postgresql should have long live persistent data since it contains all information.
Follow instructions in https://github.com/port-activity/web.
Web is standard React application that uses Ant Design component when ever possible.
React is build in a standard way. Single page application (SPA) is served as static JS bundle.
By default JS bundle could be deployed by building container that has nginx and JS bundle in same docker image. You can also deploy JS more sophisticated way in your cloud provider if you will but most cases your application will not be under so heavy traffic and there is no need to build CDN and such solutions.
This nginx configuration could be used also as proxy for other services when running containers in same namespace. See repository default.conf for setting up nginx as proxy.
Follow instructions in https://github.com/port-activity/mobile.
Mobile application is build with React Native. You need to install Expo to run application on local environment. The beauty of React Native is that you can build iOS and Android version with same code base without even opening XCode or Android Studio. Drawback is that you need make some compromises and can’t use all the fanciest platform specific features.
When building deployment packages you need create account to Expo. If you need team features you have subscribe Expos Priority plan.
Uploading application to Apple Store and Google Play store could be automated on some level with Expo. However setting up accounts to both stores is manual process. Also uploading deployment package to stores is more convenient to do manually.
When making releases withing same ExpoSDK version application JS could be deployed directly with Expo. Whenever ExpoSDK is updated full deployment package must be uploaded to stores again.
All agents have separate instructions on their repositories. Most agents follow this procedure when polling timestamps:
If exactly same timestamp data is posted Port Activity API it is ignored since it is duplicate.
Some APIs have just full lists that should be read and converted. Hovever some APIs require that you poll it with proper IMO and other query datas. For these agents there needs to be list of IMOs to poll. In such cases agent should get the list of IMOs from Port Activity API.