Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Proposed name for the project: cdbp Container-Based Development - Best Practices and Tooling

Project description:

  • Provide high level description of intended project and intended use case(s) and benefit, if needed.

Scope:

...

Container technology is a popular packaging method for developers and system administrators to build, ship and run distributed applications.

Seventy percent of respondents to a 2017's survey indicated that the existence of tools to accelerate container development is one of the key factors that drives container adoption.

The same is true for the availability of best practices. That's because Image-based container technology requires a disciplined approach to development and writing Dockerfiles and defining containerized applications can become rather complex.

Because has ONAP has adopted Docker technology, the design of good images ultimately boils down to the crafting of good Dockerfiles.

This project takes a communal approach to capturing and developing best practices, guidance, recommendations and common tools for the design of images built using Dockerfiles.

Scope:

This project will develop a specification for the recommended structure of Dockerfiles based on industry best practices

    The following are the outcomes of the project:

  •     Best practices for the design of space-efficient and scalable images built using Dockerfiles
  •     Best practices for crafting Dockerfiles
  •     Best practices for the development of platform-agnostic images
  •     Dockerfile templates to
    •      Capture, automate and share experience across projects
    •      Reduce duplication
    •      Jumpstart image development
    •      Optimize resource consumption
    •      Develop vendor-agnostic images     

Out of scope:

    This project doesn't tackle the design or architecture of microservices-based applications.


Architecture Alignment:

    The goals of this project are in perfect alignment with ONAP's architecture principles and architecture quality attributes.

    In particular, this projects suppoorts the themes adopted for Beijing and Casablanca: Platform Maturity Requirements (S3P) and Portability

    S3P alignment:

Quality AttributeBenefit of Image Design Best Practices
Scalability
  • Resource constrained images (small & fast) facilitate single and multiple ONAP instance horizontal scaling.
Manageability
  • Efficient, small images reduce transport, instantiation time and upgrade time.
Usability
  • Dockerfile templates save time and resources by increasing re-usability and reducing development and testing cycles.
  • Re-usable base images reduce project jumpstart overhead.
  • Multi-platform containers based on official multi-cpu architecture base images allows operators to choose among a larger number of cloud/infrastructure providers.

Security
  • Images built using the latest official base images reduce the risk of deploying containers with vulnerabilities.

   

Portability


 Software portability is the ability to use the same software artifacts (images/containers) in different environments.

For ONAP aims at enabling deployments of the orchestration platform and VNFs in different cloud infrastructure providers.

Furthermore, cloud infrastructure providers may choose among variety of hardware/server providers with different OS and cpu architectures.

Having best practices and Dockerfile templates that simplify the use of official multi-platform (OS, CPU) base images makes ONAP portable by enabing  ONAP deployment in diferent environments.   

Other Information:

  • Vendor Neutral

...

Architecture Alignment:

  • How does this project fit into the rest of the ONAP Architecture?
    • Please Include architecture diagram if possible
    • What other ONAP projects does this project depend on?
  • How does this align with external standards/specifications?
    • APIs/Interfaces
    • Information/data models
  • Are there dependencies with other open source projects?
    • APIs/Interfaces
    • Integration Testing
    • etc.

Other Information:

  • link to seed code (if applicable)
  • Vendor Neutralif the proposal is coming from an existing proprietary codebase, have you ensured that all proprietary trademarks, logos, product names, etc., have been removed?
  • Meets Board policy (including IPR)

Use the above information to create a key project facts section on your project page

Key Project Facts:

Facts

Info

PTL (first and last name)
Jira Project Namecdbp
Jira Key
Project IDcdbp
Link to Wiki Space

Release Components Name:

Note: refer to existing project for details on how to fill out this table

Components Name

Components Repository name

Maven Group ID

Components Description

Dockerfile templatesdocker_templatesorg.onap.docker_templates




Resources committed to the Release:

Note 1: No more than 5 committers per project. Balance the committers list and avoid members representing only one company. Ensure there is at least 3 companies supporting your proposal.

...