[Feature request] need an apollo-operator for LCM by cloud native way

[wilsonwu]

Is your feature request related to a problem? Please describe.
Under Cloud Native world, it is hard to manage apollo instances.

Describe the solution you'd like
Create an operator to do LCM.

Describe alternatives you've considered
Also can do LCM by k8s apis, but it is hard and inefficient.

Additional context
No more.

[nobodyiam]

Sounds a good idea.

[JaredTan95]

hi, @wilsonwu,
Agree with your suggestion, Operator is currently the most common way for cloud-native, and happy to see the Apollo-Operator sub-project, but, before that, we need to have a rough design that allows other apollo PMC members of the community to participate in the review.

From my understanding, I roughly think that the operator should include the following CRD or cr resources, just for reference:

• For external Mysql DB, you need to create the secret for Apollo-operator using it.

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Secret
metadata:
  name: myapollodbsecret
type: Opaque
data:
  # KEY: base64-encoded string
  HOST: my-apollometaserver-db
  PORT: DFlMmU2
  USER_NAME: YWRtaW4=
  PASSWORD: MWYyZDFlMmU2N2Rm
EOF

• ApolloEnvironment: configservice/k8s-metaservice + adminservice

cat <<EOF | kubectl apply -f -
apiVersion: k8s.apolloconfig.com/v1
kind: AplloEnvironment
metadata:
  name: quickstart-apollo-env
spec:
  version: yyy
  configServiceCount: 1
  adminServiceCount: 1
  mysqlEmbedded: true # this embedded mysql noly for POC or demo. otherwise, you need to use external db way.
  envId: one of LOCAL, DEV, BETA, FWS, FAT, UAT, LPT, PRO, TOOLS, UNKNOWN; https://github.com/apolloconfig/apollo/blob/master/apollo-core/src/main/java/com/ctrip/framework/apollo/core/enums/Env.java
  mysql:
    host: my-apollo-mysql-db
    dbname: apollo_config
  #mysql:
 #.    secretRef: the secret of extenal db url and username/password. that means you should create secret before apply AplloEnvironment CRDs. 
#      secretRef :myapollodbsecret
  env:
    - name: JAVA_OPTS
      value: -Xmx2048M
EOF

• AplloPortal: portal service

cat <<EOF | kubectl apply -f -
apiVersion: k8s.apolloconfig.com/v1
kind: AplloPortal
metadata:
  name: quickstart
spec:
  version: 0.0.1
  count: 1
  mysql:
 #.    secretRef: the secret of extenal db url and username/password. that means you should create secret before apply AplloEnvironment CRDs. 
#      secretRef :myapollodbsecret
  apolloEnvRef:
    - name: quickstart-apollo-env
    - name: another-quickstart-apollo-env
    - name: upgrade-quick-apollo-env
  env:
    - name: JAVA_OPTS
      value: -Xmx2048M
EOF

• All-In-One(configservice + admin + portal + memory/DB) for demo

cat <<EOF | kubectl apply -f -
apiVersion: k8s.apolloconfig.com/v1
kind: Apllo
metadata:
  name: quickstart
spec:
  version: 0.0.1
  count: 1
  env:
    - name: JAVA_OPTS
      value: -Xmx2048M
EOF

BTW, It is also worth mentioning that apollo involves some writes and reads of the database, which is a more complex, I think that the early of the operator can avoid this part of the operation when doing apollo upgrade and unload, and inform users how to manually clean the database in the form of documents. @nobodyiam What do you think？

[nobodyiam]

@JaredTan95

Thanks for elaborating on this topic.
From my understanding, CRD is the key part of the operator pattern that users could simply declare their intentions by submitting CRs to K8S and letting the operator fulfill the users' intentions.
The intentions may include:

1. initial installation
   For example, the database connection, the replica of the apollo-portal/apollo-adminservice/apollo-configservice, the configurations like the meta service URLs, etc.
   Speaking of this, there is a helm chart project that does a similar job. We may think about what's the difference between them.

2. upgrading
   This is a more important topic as it may affect the production availability. Via the operator, I believe it's easy to do a more granular upgrading step.

3. operation
   There are also some operations that are complex to do, e.g. adding an environment. Via the operator, users could simply submit a CR that describes the environment and let the operator do the rest, e.g. config the env to apollo-portal, copy metadata from other env, etc.

So I think we could start by designing the CRD definitions and their intended behaviors.

[JaredTan95]

So I think we could start by designing the CRD definitions and their intended behaviors.

yes, that's a good and suitable orientation.

[stale]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in 7 days unless it is tagged "help wanted" or other activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in 7 days unless it is tagged "help wanted" or other activity occurs. Thank you for your contributions.

[wilsonwu]

https://github.com/apolloconfig/apollo-operator, the operator repo is ready, let's contribute.

[dosubot]

🤖

It seems like we need your expertise on this one, @nobodyiam.

---

This response is meant to be useful and save you time. It is not meant to be a precise solution, but rather a starting point for your own research.

Help me be more useful! Please leave a 👍 if this is helpful and 👎 if it is irrelevant.

If you want to continue the conversation, start your reply with @dosu-bot.