Skip to content
A Hyper Protect secure Swift application using Kitura
JavaScript Other
Branch: master
Clone or download
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
Sources Automated Update May 31, 2019
Tests Automated Update Dec 20, 2018
config
debian
definitions Automated Update Dec 20, 2018
docs/services Automated Update Dec 20, 2018
images [ImgBot] Optimize images Apr 18, 2019
public [ImgBot] Optimize images Apr 18, 2019
terraform Automated Update Dec 20, 2018
.cfignore
.dockerignore Automated Update Dec 20, 2018
.gitignore Automated Update Dec 20, 2018
.swift-version
.swiftservergenerator-project Automated Update Dec 20, 2018
.yo-rc.json Automated Update Mar 26, 2019
CONTRIBUTING.md
Dockerfile Automated Update May 31, 2019
Dockerfile-tools
Jenkinsfile Automated Update Dec 20, 2018
LICENSE
MAINTAINERS.md Automated Update Dec 20, 2018
NOTICES.txt Automated Update Apr 4, 2019
Package.swift Automated Update May 31, 2019
README.md Light edit and topicID link updates. (#23) Jul 5, 2019
cli-config.yml
iterative-dev.sh Automated Update Dec 20, 2018
manifest.yml Automated Update Dec 20, 2018

README.md

Platform

Create a Hyper Protect secure Swift application using Kitura

In this code pattern, you will create a server-side application using Kitura in Swift and Hyper Protect Services. Hyper Protect Services bring continuous security to IBM Cloud, so all data is encrypted in flight, at rest, and in use.

When you have completed this code pattern, you will understand how to:

  • Provision and integrate Hyper Protect Services.
  • Generate an application with files for deploying to Kubernetes, Cloud Foundry or a DevOps Pipeline.
  • Generate an application with files for monitoring and distributed trace using App Metrics.
  • Connect to additional provisioned services.

As an alternative to the deployment options documented below, you can create this project as a starter kit on IBM Cloud, which injects service credentials into a custom fork of this pattern after you have provisioned the database with your specifications. Use this method to deploy to IBM Cloud with the click of a button.

You will need to provision the Hyper Protect DBaaS service yourself, providing parameters like password. Make sure to select a service plan for MongoDB, as this sample does not yet work with its PostgreSQL offering.

Project contents

This application has been generated with the following capabilities and services, which are described in full in their respective sections below:

Requirements

Run

To build and run the application:

  1. swift build
  2. swift run

Docker

A description of the files related to Docker can be found in the Docker files setion. To build the two docker images, run the following commands from the root directory of the project:

  • docker build -t myapp-run .
  • docker build -t myapp-build -f Dockerfile-tools . You may customize the names of these images by specifying a different value after the -t option.

To compile the application using the tools docker image, run:

  • docker run -v $PWD:/swift-project -w /swift-project myapp-build /swift-utils/tools-utils.sh build release

To run the application:

  • docker run -it -p 8080:8080 -v $PWD:/swift-project -w /swift-project myapp-run sh -c .build-ubuntu/release/swiftkiturahyperprotectdbaas

Kubernetes

To deploy your application to your Kubernetes cluster, run helm install --name myapp . in the /chart/swiftkiturahyperprotectbaas directory. You need to make sure you change the repository variable in your chart/swiftkiturahyperprotectdbaas/values.yaml file points to the docker image containing your runnable application.

Configuration

Your application configuration information for any services is stored in the localdev-config.json file in the config directory. This file is in the .gitignore to prevent sensitive information from being stored in git. The connection information for any configured services that you would like to access when running locally, such as username, password and hostname, is stored in this file.

The application uses the CloudEnvironment package to read the connection and configuration information from the environment and this file. It uses mappings.json, found in the config directory, to communicate where the credentials can be found for each service.

If the application is running locally, it can connect to IBM Cloud services using unbound credentials read from this file. If you need to create unbound credentials you can do so from the IBM Cloud web console (example), or using the Cloud Foundry CLI cf create-service-key command.

When you push your application to IBM Cloud, these values are no longer used, instead the application automatically connects to bound services using environment variables.

Iterative Development

The iterative-dev.sh script is included in the root of the generated Swift project and allows for fast and easy iterations for the developer. Instead of stopping the running Kitura server to see new code changes, while the script is running, it will automatically detect changes in the project's .swift files and recompile the app accordingly.

To use iterative development:

  • For native OS, execute the ./iterative-dev.sh script from the root of the project.
  • With docker, shell into the tools container mentioned above, and run the ./swift-project/iterative-dev.sh script. File system changes are detected using a low-tech infinitely looping poll mechanism, which works in both local OS/filesystem and across host OS->Docker container volume scenarios.

Deploy to IBM Cloud

You can deploy your application to IBM Cloud using the Cloud Foundry CLI.

You can deploy the application to IBM Cloud using the Cloud Foundry command-line:

  1. Install the Cloud Foundry command-line
  2. Ensure all configured services have been provisioned
  3. Run cf push from the project root directory

The Cloud Foundry CLI will not provision the configured services for you, so you will need to do this manually using the IBM Cloud web console (example) or the CloudFoundry CLI (cf create-service command)[http://cli.cloudfoundry.org/en-US/cf/create-service.html]. The service names and types will need to match your configuration.

Service descriptions

Static web file serving

This application includes a public directory in the root of the project. The contents of this directory will be served as static content using the built-in Kitura StaticFileServer module.

This content is hosted on /. For example, if you want to view public/myfile.html and the application is hosted at https://localhost:8080, go to https://localhost:8080/myfile.html.

OpenAPI / Swagger endpoint

This application hosts an endpoint for serving the OpenAPI Swagger definition for this application. It expects the definition file to be located in definitions/swiftkiturahyperprotectdbaas.yaml.

The endpoint is hosted on /swagger/api. For example, if the application is hosted at https://localhost:8080, go to https://localhost:8080/swagger/api.

Example endpoints

This application includes an OpenAPI Swagger definition and routes for a Product example resource. The OpenAPI Swagger definition is located in the definitions/swiftkiturahyperprotectdbaas.yaml directory.

The specification of this interface is made available through an embedded Swagger UI hosted on /explorer. For example, if the application is hosted at https://localhost:8080, go to https://localhost:8080/explorer.

The Swagger UI will document the paths and http methods that are supported by the application.

Embedded metrics dashboard

This application uses the SwiftMetrics package to gather application and system metrics.

These metrics can be viewed in an embedded dashboard on /swiftmetrics-dash. The dashboard displays various system and application metrics, including CPU, memory usage, HTTP response metrics and more.

Docker files

The application includes the following files for Docker support:

  • .dockerignore
  • Dockerfile
  • Dockerfile-tools

The .dockerignore file contains the files/directories that should not be included in the built docker image. By default, this file contains the Dockerfile and Dockerfile-tools. It can be modified as required.

The Dockerfile defines the specification of the default docker image for running the application. This image can be used to run the application.

The Dockerfile-tools is a docker specification file similar to the Dockerfile, except it includes the tools required for compiling the application. This image can be used to compile the application.

Details on how to build the docker images, compile and run the application within the docker image can be found in the Run section.

IBM Cloud deployment

Your application has a set of cloud deployment configuration files defined to support deploying your application to IBM Cloud:

  • manifest.yml
  • .bluemix/toolchain.yml
  • .bluemix/pipeline.yml

The manifest.yml defines options which are passed to the Cloud Foundry cf push command during application deployment.

Next steps

Leverage the IBM Cloud DevOps service, which provides toolchains as a set of tool integrations that support development, deployment, and operations tasks inside IBM Cloud, for both Cloud Foundry and Kubernetes applications.

License

This code pattern is licensed under the Apache License, Version 2. Separate third-party code objects invoked within this code pattern are licensed by their respective providers pursuant to their own separate licenses. Contributions are subject to the Developer Certificate of Origin, Version 1.1 and the Apache License, Version 2.

Apache License FAQ

You can’t perform that action at this time.