• github
    K-PaaS github
    Millions of developers use Github to build personal projects, support businesses, and collaborate with open source technologies.
  • K-PaaS incubator
    K-PaaS Incubator
    We are helping companies utilize K-PaaS.
  • cloudfoundry
    Cloud Foundry
    Cloud Foundry gives businesses the speed, simplicity, and control they need to quickly and easily develop and deploy applications.
  • youtube
    We support open cloud platform K-PaaS related videos.

Application Platform - v5.8.9

This is an application platform configuration diagram of the open cloud platform K-PaaS.
The application platform is built on top of Cloud Foundry open source.

Application Platform Components

    • router
      • gorouter
    • tcp-router
      • tcp-router
    • uaa
      • uaa
      • statsd_iniector
    • credhub
      • credhub
  • APP
    • api
      • cloud_controller_ng
      • ***-buildpack
      • statsd_iniector
      • file-server
      • routing-api
      • policy-server
      • policy-server-internal
      • cc-udp-forwarder
    • cc-worker
      • cloud_controller_worker
    • database
      • mysql ⁄ postgres
    • diego-api
      • cfdot
      • bbs
      • silk-controller
      • locket
      • loggr-udp-forwarder
    • scheduler
      • cfdot
      • auctioneer
      • cloud_controller_clock
      • cc_deployment_updater
      • service-discovery-controller
      • statsd_iniector
      • tps
      • ssh_proxy
      • loggr-syslog-binding-cache
      • loggr-udp-forwarder
  • APP
    • diego-cell
      • bosh-dns-adapter
      • cflinuxfs3-rootfs-setup
      • garden
      • rep
      • cfdot
      • route_emitter
      • graden-cni
      • netmon
      • vxlan-policy-agent
      • silkdemon
      • silk-cni
      • loggr-udp-forwarder
    • singleton-blobstore
      • blobstore
    • nats
      • nats
      • nats-tls
  • METRIC ⁄
    • doppler
      • doppler
    • log-api
      • loggregator_trafficcountroller
      • reverse_log_proxy
      • reverse_log_proxy_gateway
    • log-cache
      • log-cache
      • log-cache-cf-auth-proxy
      • log-cache-gateway
      • log-cache-syslog-server

Functions and Roles of the Components

  • 1 Router
    It is responsible for routing user Http request traffic to its destination. The main destination will be the Cloud Controller or Garden Container running the application. Router's router information receives the application instance information that Diego is servicing from Nats and is updated through Route-emitter. The route-emitter module has been integrated into Diego-Cell.
    Git source : https://github.com/cloudfoundry/gorouter
  • 2 Tcp-Router
    It serves to route user Tcp request traffic to the destination. The main destination will be the Garden Container running the application.The router information of the router receives the application instance information that Diego is servicing from Nats and is updated through the route-emitter. The route-emitter module has been integrated into Diego-Cell.
    Git source : https://github.com/cloudfoundry/cf-tcp-router/
  • 3 API(Cloud Controller)
    Provides APIs for staging and running applications. Responsible for overall management of the application, such as build pack selection, service and binding, and access authorization processing. When a developer sends an application to Cloud Foundry via CLI, the Cloud Controller receives it, which stores the application binary, creates a record of application metadata, and communicates with Diego to instruct Stage state preparation and application execution. For services, Cloud Controller maintains a database for holding information such as organizations, spaces, services, service instances, user roles, and blob storage for storing application code and buildpacks, etc.
    Git source : https://github.com/cloudfoundry/cloud_controller_ng
  • 4 UAA
    It acts as an OAuth2 server and login server to provide user authentication management.
    Git source : https://github.com/cloudfoundry/uaa
  • 5 CC-Worker
    Execute task (App LifeCycle, etc.) requested by API in BackGround.
    Git source : https://github.com/cloudfoundry/cloud_controller_ng
  • 6 Scheduler(Auctioneer)
    It is a VM with existing Auction and decides which cell to deploy the App Container.
    Git source : https://github.com/cloudfoundry-incubator/auctioneer
  • 7 Database
    It is a database storage where K-PaaS's Tennant, App, and authentication information are stored, and it is composed of Postgres/MySql.
  • 8 Diego-cell(Rep)
    It represents Cell and performs various services through BBS. In other words, it checks whether the task and ActualLRP information of the BBS matches the actual container in the cell, and maintains the cell in the BBS to exist. If a particular Cell fails, Converger automatically transfers that instance to another Cell. In addition, it participates in Auction to receive Tasks/LRP, makes a request to the Executor, executes Tasks/LRPs to create a container, and executes the action to be performed within the container.
    Git source : https://github.com/cloudfoundry-incubator/rep
  • 9 Diego-cell(Executor)
    It provides HTTP APIs for creating containers, performing actions within containers, and deleting containers. It does not distinguish between Task and LRP, and implements Action API for performing actions. Executor sends Stdout and Stderr streams to metro-agent running in Cell, and the streams are passed to Loggregator.
    Git source : https://github.com/cloudfoundry-incubator/executor
  • 10 Diego-cell(Garden)
    It provides platform-independent server and client interfaces for container management. The interface defines methods for performing the following actions
    - Creation and deletion of containers
    - Applying resource constraints of containers
    - Connecting and developing network ports to containers
    - Copy files into/out of container
    - Process execution in container and handling Stdout and Stderr data streaming
    - Arbitrary meta data in the container
    - Create container snapshots for redeployment without downtime
    Currently, Garden-linux is provided as a Linux implementation that implements the Garden interface.
    Git source : https://github.com/cloudfoundry-incubator/garden
  • 11 Diego-cell(route-emitter)
    It monitors the actual LRP (ActualLRP) status from the rep, compares it with the target LRP (DesiredLRP) , and sends a request message to register/remove route information to the Router through nats if a change occurs. Periodically sends the entire routing table to the Router.
    Git source : https://github.com/cloudfoundry-incubator/route-emitter
  • 12 Nats
    App domain information running in K-PaaS is received from route-emitter and delivered to router.
    Git source : https://github.com/apcera/gnatsd
  • 13 Doppler
    Doppler provides application logs to developers as a stream.
    Git source : https://github.com/cloudfoundry/loggregator/
  • 14 Diego-api
    It is a VM running the existing BBS and checks the running state of the container.
    Git source : https://github.com/cloudfoundry/bbs
  • 15 singleton-blobstore
    An object repository that stores K-PaaS's application packages, staged application droplets, and buildpack caches. It can be configured as internal or external .
    Git source : https://github.com/cloudfoundry/capi-release/tree/develop/jobs/blobstore
  • 16 log-api
    Each component of the application platform generates a system log, and a deployed application generates an app log.
    The Loggregator system structures and collects each component's metrics and app logs into Firehose, and all outputs from Firehose are available and can be exported for specific purposes, such as monitoring systems, triggering alert systems, and analyzing user behavior.
  • 17 credhub
    CredHub is a component designed for centralized credential management for application platforms. At the highest level, CredHub centralizes and secures credential creation, storage, lifecycle management, and access.
  • 18 log-chace
    Logs and metrics can be shown for the specified period using the log cache. The log cache includes API endpoints and CLI plugins that query and filter logs and metrics.

Application Deployment`s Flow

12단계의 흐름 하단 상세설명 참조
  • 1Developer (user) executes “$ cf push”
  • 2cf CLI (The Cloud Foundry Command Line Interface) requests the Cloud Controller to create data for
           the application.
  • 3Cloud Controller stores application metadata (application name, number of instances, buildpack,
  • 4Perform the following tasks
    1. a. cf CLI requests the Cloud Controller to match the resources using the application name.
    2. b. cf CLI uploads application source files, existing caching resources and other source files.
    3. c. Cloud Controller creates an application package by combining uploaded files and caching
  • 5Cloud Controller stores application packages in blobstore.
  • 6cf CLI requests to start the application.
  • 7Perform the following tasks.
    1. a. Cloud Controller requests Diego to stage.
    2. b. Diego schedules Diego Cell to run the staging job.
    3. c. Download the list of buildpacks and the application buildpack cache (if any).
    4. d. Compile and stage the application using the buildpack.
  • 8Diego Cell streams the output of the staging process. Developers can check the output for
           troubleshooting during the staging phase.
  • 9Perform the following tasks.
    1. a. Create a droplet or tarball with a compiled and staged application.
    2. b. Diego Cell stores the Droplet in the blobstore.
    3. Upload the buildpack cache to the blobstore for later staged application use.
  • 10BBS (Diego Bulletin Board System) reports to Cloud Controller that staging is complete. If staging is
           not completed within 15 minutes, it is treated as a failure.
  • 11Diego reserves the application with LRP (Long-Running Process) in one or more Diego Cells.
  • 12Diego Cell reports the status of the application to the Cloud Controller.

Details in the Diego cell among the components of K-PaaS when the application is actually deployed

Start distributing the application based on the developed source or build file
Application Compliation은 시작: 배포 명령 실행 다음 Diego 컨테이너 생성 다음 Application 코드 배치 다음 적합한 Buildpack찾기 다음 컴파일 진행 끝
Droplet storage that can be distributed at any time in Diego-cell
Staging is Complete은 시작: Droplet Archive(Application이 동작할 수 있는 부가 요소를 모두 갖춘 형태) 다음 Blobstore에 저장 끝
Start user application service
Running an Application은 시작:Application Instance가 실행될 새로운 컨테이너 생성 요청 다음 release 스크립트 실행 다음 Application 동작 끝

Open Source List

Open Source List
Service Group Service Name Opensource Name License Remark
Application Platform CF deployment bosh-dns Apache2.0  
bosh-dns-aliases Apache2.0  
bpm Apache2.0  
capi Apache2.0  
cf-cli Apache2.0  
cf-networking Apache2.0  
cf-smoke-tests Apache2.0  
cf-syslog-drain Apache2.0  
cflinuxfs3 Apache2.0  
credhub Apache2.0  
diego Apache2.0  
garden-runc Apache2.0  
haproxy Apache2.0  
log-cache Apache2.0  
loggregator Apache2.0  
loggregator-agent Apache2.0  
nats Apache2.0  
postgres Apache2.0  
pxc Apache2.0  
routing Apache2.0  
statsd-injector Apache2.0  
silk Apache2.0  
syslog Apache2.0  
uaa Apache2.0  
buildpack binary-buildpack Apache2.0  
dotnet-core-buildpack Apache2.0  
go-buildpack Apache2.0  
java-buildpack Apache2.0  
nginx-buildpack Apache2.0  
nodejs-buildpack Apache2.0  
php-buildpack Apache2.0  
python-buildpack Apache2.0  
r-buildpack Apache2.0  
ruby-buildpack Apache2.0  
staticfile-buildpack Apache2.0