Apply theory in accordance with the rule of 12
-
Codebase: Put all your code in a version control system (such as Git or Mercurial). What is deployed is entirely determined by the benchmark code.
-
Dependencies: Application Dependencies should all be managed explicitly by the benchmark code, either by vendor (stored together with the application code) or by dependency profiles that are parsed and installed by package management software.
-
Config: Separate application configuration parameters from the application itself. Configuration should be defined in the deployment environment, not embedded in the application itself.
-
Backing Services: Dependent Services, both local and remote, should be abstracted as resources accessible over the network, and connection details should be defined in the configuration.
-
Build, Release, Run: The Build phase of your application should be completely separate from the release, operation and maintenance phases. The build phase creates an executable from the application source, the release phase combines the executable with the configuration, and then executes the release at run time.
-
Processes: Applications should be implemented by Processes that do not depend on any local state store. State should be stored in the back-end service described in Rule 4.
-
Port binding: Applications should natively bind ports and listen for connections. All routing and request forwarding should be handled externally.
-
Concurrency: An application should rely on process model extensions. Simply by running multiple applications at the same time, possibly on different servers, you can achieve the goal of not adjusting the application code extension.
-
Disposability: Processes should be able to be quickly started and gracefully shut down without causing any serious side effects.
-
Dev/ Prod Parity: Your testing, pre-release, and online environments should be as consistent and synchronized as possible. Differences between environments can cause compatibility problems and untested configurations to crop up.
-
Logs: The application should output the Logs to stDout and let external services decide the best way to handle them.
-
Admin Processes: One-off administrative processes should be distributed with the main process code and run on a particular release.
Container optimization criterion
Enhance Pod functionality by tying it to a supporting container
-
Sidecar (Sidecar mode) : In this mode, the secondary container extends and enhances the core functionality of the primary container. This pattern involves performing non-standard or utility functions in a separate container. For example, a container that forwards logs or listens for configuration changes can extend the functionality of a POD without changing its primary concern.
-
Ambassador Pattern: The Ambassador pattern uses a supporting container to abstract remote resources for the host container. The main container connects directly to the Ambassador container, which in turn connects to a potentially complex external resource pool — say, a distributed Redis cluster — and performs resource abstraction. The master container can complete the wiring of external services without knowing or caring about their actual deployment environment.
-
Adaptor: The Adaptor pattern is used to translate data, protocols, or interfaces used by the host container to align with standards expected by external users. Adaptor containers can also unify access points to central services, even if the users they serve originally support only incompatible interface specifications.
Access Services from within
Open Services to the Public network
The Kubernetes project practical training will start on August 17, 2018 in Shenzhen. It will take you 3 days to master Kubernetes systematically
.
