Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dynamic environment for apollo-portal #2867

Conversation

Anilople
Copy link
Contributor

What's the purpose of this PR

Add a feature, make portal support self-define environment without change 1 line code.
Only config will be changed.

Brief changelog

Dynamic environment setting when portal service start.
A new way to forbidden changing hard code to add new environment.
Just change 2 configuration properties.
Suppose that you want to add a new environment beta, and you have been add dev, just do like follow step.

  1. change apollo.portal.envs.Just change its value to dev,beta in db or add VM option -Dapollo.portal.envs=dev,beta
  2. add property beta.meta=your-meta-address or add VM option -Dbeta_meta=your-meta-address

There are 4 fake classes added under package com.ctrip.framework.apollo.portal.environment,
the purpose is using them to replace the classes in apollo-core.

But only 1 fake class exists testing, the rest 3 classes lack the unit testing.

Could I cancel the function 3rd party MetaServerProvider could be injected by typical Java Service Loader pattern. in com.ctrip.framework.apollo.portal.environment.PortalMetaDomainConsts, and make its loading to be not lazy ?

Follow this checklist to help us incorporate your contribution quickly and easily:

  • Read the Contributing Guide before making this pull request.
  • Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
  • Write necessary unit tests to verify the code.
  • Run mvn clean test to make sure this pull request doesn't break anything.

@coveralls
Copy link

coveralls commented Dec 24, 2019

Coverage Status

Coverage remained the same at ?% when pulling 27dc65b on Anilople:dynamic-portal-env-nochange-with-apollo-core into b718007 on ctripcorp:master.

@codecov-io
Copy link

codecov-io commented Dec 24, 2019

Codecov Report

Merging #2867 into master will not change coverage.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff            @@
##             master    #2867   +/-   ##
=========================================
  Coverage     51.05%   51.05%           
  Complexity     2197     2197           
=========================================
  Files           429      429           
  Lines         13235    13235           
  Branches       1360     1360           
=========================================
  Hits           6757     6757           
  Misses         6005     6005           
  Partials        473      473
Impacted Files Coverage Δ Complexity Δ
...framework/apollo/core/signature/HmacSha1Utils.java 62.5% <100%> (ø) 1 <0> (ø) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9e81618...27dc65b. Read the comment docs.

Copy link
Member

@nobodyiam nobodyiam left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This feature looks great! I think this will greatly reduce the complexitiy to add a customized environment.

for (String env : envArray) {
if (Strings.isNullOrEmpty(env)) {
continue;
} else {
Copy link
Member

@nobodyiam nobodyiam Jan 1, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this else { statement is unnecessary?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From the git history. The code is merged from other branch.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the else { statement was removed in pr #2864 , so I guess it was brought back to this branch when you resolved the merging conflicts.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Change back already.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the whole file rolled back? I think we still need to change the import statement import com.ctrip.framework.apollo.portal.environment.Env;?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've changed it by accident. A new commit has pushed.

Copy link
Member

@nobodyiam nobodyiam left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is also some conflict with master branch, please help to solve it, thx.

* @see com.ctrip.framework.apollo.core.MetaDomainConsts
* @author wxq
*/
public class PortalMetaDomainConsts {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add unit test for PortalMetaDomainConsts

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In apollo-core, there is a test for MetaDomain, i.e com.ctrip.framework.apollo.core.MetaDomainTest. It seems that implements com.ctrip.framework.apollo.BaseIntegrationTest, and start a internal server to test.

If i want to write the unit test of com.ctrip.framework.apollo.portal.environment.PortalMetaDomainConsts, should i use the same way?

A little Challenge to do this. (hard)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need to do it and it looks like you have done that part

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The unit test is done.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Most code is copied from apollo-core

metaServerAddressesFromSystemProperty = KeyValueUtils.removeKeySuffix(metaServerAddressesFromSystemProperty, "_meta".length());

// find key-value from OS environment variable which key ends with "_meta"
Map<String, String> metaServerAddressesFromOSEnvironment = KeyValueUtils.filterWithKeyEndswith(System.getenv(), "_meta");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OS Environment variables are normally in UPPER CASE, so it might be better to check with _META

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've change the rule of match suffix to case insensitive.

metaServerAddressesFromOSEnvironment = KeyValueUtils.removeKeySuffix(metaServerAddressesFromOSEnvironment, "_meta".length());

// find key-value from properties file which key ends with ".meta"
Properties properties = new Properties();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it might be better to also support setting meta server address from PortalDB.ServerConfig, which is the same place to store apollo.portal.envs and is therefore more intuitive, e.g. user can set env and env meta server address in System Configuration page. How do you think?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You mean the meta server addresses are save in apollo.portal.envs which type is a map?
the config like follow:

apollo:
  portal:
    envs:
      dev: http://ip:port
      other: http://ip:port
      self-define: http://ip:port

And in PortalDB.ServerConfig's apollo.portal.envs, there is a json object

{
      "dev"" : "http://ip:port"
      "other" : "http://ip:port"
      "self-define" : "http://ip:port"
}

So then portal conbine those config to get the meta server addresses?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this feature (add environment in portal when running) will consume more code to implement.
How about when this feature (add environment in portal when start up) finished, next plan to do it?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can keep it as add environment in portal when start up, but we support configuring it via System Configuration page, e.g. we add a new configuration item like apollo.portal.meta.servers to store the mapping between env and meta server address.

We will still keep the apollo.portal.envs as it indicates the active environments so that there may be 3 environment mappings in apollo.portal.meta.servers but only 2 active envs in apollo.portal.envs.

If this involves much more effort, then it's okay to leave it when we support add environment in portal when running.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Get it.
It involves the Database operations. Add new key apollo.portal.meta.servers, and refresh it in runtime.
I feel that the database operation is a bit difficult.
I don't know how to add this feature now.

@nobodyiam nobodyiam changed the title Dynamic environment without apollo-core Env (make a fake Env in apollo-portal) Dynamic environment for apollo-portal Jan 5, 2020
Copy link
Member

@nobodyiam nobodyiam left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM for now

@nobodyiam nobodyiam merged commit 42edb9d into apolloconfig:master Jan 5, 2020
@nobodyiam nobodyiam mentioned this pull request Jan 5, 2020
4 tasks
@nobodyiam nobodyiam added this to the 1.6.0 milestone Feb 16, 2020
nobodyiam added a commit to nobodyiam/apollo that referenced this pull request Feb 22, 2020
@nobodyiam nobodyiam mentioned this pull request Feb 22, 2020
4 tasks
nobodyiam added a commit that referenced this pull request Feb 22, 2020
@Anilople Anilople mentioned this pull request Mar 10, 2020
4 tasks
@Anilople Anilople added area/portal apollo-portal feature Categorizes issue as related to a new feature. labels Dec 23, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/portal apollo-portal feature Categorizes issue as related to a new feature.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants