Scaffolded Swift Kitura server application
This scaffolded application provides a starting point for creating Swift applications running on Kitura.
Table of Contents
- Project contents
- Deploy to IBM Cloud
- Service descriptions
This application has been generated with the following capabilities and services, which are described in full in their respective sections below:
To build and run the application:
A description of the files related to Docker can be found in the Docker files section. To build the two Docker images, run the following commands from the root directory of the project.
First, build the 'tools' image. This image contains a full Linux Swift toolchain and is capable of compiling your application for Linux:
docker build --tag myapp-build --file Dockerfile-tools .You may customize the names of these images by specifying a different value after the
To compile the application for Linux using the tools Docker image, run:
docker run --volume $PWD:/swift-project --workdir /swift-project myapp-build /swift-utils/tools-utils.sh build releaseThis produces a
.build-ubuntudirectory which will be incorporated into your final image.
Now that your application has been built, you can build the final run image:
docker build --tag myapp-run .
Finally, to run the application:
docker run -it --publish 8080:8080 myapp-run
To deploy your application to your Kubernetes cluster, run
helm install --name myapp . in the
/chart/ToDoList directory. You need to make sure you change the
repository variable in your
chart/ToDoList/values.yaml file points to the docker image containing your runnable application.
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 CloudFoundry 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-dev.sh script is included in the root of the generated Swift project and allows for fast & 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.shscript from the root of the project.
- With docker, shell into the tools container mentioned above, and run the
./swift-project/iterative-dev.shscript. 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:
You can deploy the application using the IBM Cloud command-line:
- Install the IBM Cloud CLI
- Ensure all configured services have been provisioned
ibmcloud app pushfrom 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.
IBM Cloud toolchain
You can also set up a default IBM Cloud Toolchain to handle deploying your application to IBM Cloud. This is achieved by publishing your application to a publicly accessible github repository and using the "Create Toolchain" button below. In this case configured services will be automatically provisioned, once, during toolchain creation.
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.
The application includes the following files for Docker support:
.dockerignore file contains the files/directories that should not be included in the built docker image. By default this file contains the
Dockerfile-tools. It can be modified as required.
Dockerfile defines the specification of the default docker image for running the application. This image can be used to run the application.
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 defines options which are passed to the Cloud Foundry
cf push command during application deployment.
IBM Cloud DevOps service 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. The "Create Toolchain" button creates a DevOps toolchain and acts as a single-click deploy to IBM Cloud including provisioning all required services.
All generated content is available for use and modification under the permissive MIT License (see
LICENSE file), with the exception of SwaggerUI which is licensed under an Apache-2.0 license (see
This project was generated with generator-swiftserver v5.15.0.
Help us keep the lights on