These are chat archives for spring-cloud/spring-cloud

12th
Oct 2018
yuanxu zhang
@yuanxuzhang
Oct 12 2018 03:30
image.png
image.png
anyone encountered this problem?
Martin Van Krieken
@mvankrieken
Oct 12 2018 12:19
@chad_d_stud_twitter Is this (https://blog.csainty.com/2016/09/bootstrap-eureka-with-dns.html) setup not an option for you? For your costs question relating to AWS. If you go to https://calculator.s3.amazonaws.com/index.html, you can put in your setup and check if it differs that much. As far as i know, 1 x t2.medium is the same price as 2 x t2.small. From that point its cheaper on the long run, to have smaller machines, because if you ever do want to scale up, you scale up more precise.
Martin Van Krieken
@mvankrieken
Oct 12 2018 12:32

@bsushant-athena I think it has more todo with how the eureka services works internally. It will try to find the 'closest' one by default. Which means the one in the same availability zone. Beyond this fact, how many eureka servers you want to have if up to you. I would minium 2. From some guidelines 3 (you are doing maintenance on 1, 1 goes down and you are still up) you should not be bothered where the machines run. For example i made it using the elastic-ip. I defined 1 elastic-ip for each zone. If a AWS zone would go down, the server could not bootup anymore in that zone, but will then take a non-allocated ip from the whole range (3) and boot up in another zone, so you will still end up with 3 eureka servers. The same would happen for any microservice that was running the zone that went done. It will be booted up in another zone.

As a general notice. Try to avoid using internal load balancers between microservies as it counters the effect of using the discovery service.

Martin Van Krieken
@mvankrieken
Oct 12 2018 12:43
@yuanxuzhang Seems you have a connection problem between the microservice and the discovery-service. If i would need to gues, it means that you had a service running which your trying to reach, but it was marked as unhealthy. As it could not refresh the register to load 'new' servers, you have 'no known servers' left that could execute the request.
springroll12
@springroll12
Oct 12 2018 13:37
Hello again. I am still very confused about how to manage secrets properly in a cloud environment. I thought it made sense to have one (hashicorp) Vault instance which serves many clusters. The Vault instance will serve as a backend to the config-server in each cluster, but I would hope that it would only be needed to bootstrap instances of services (no need for setting secrets in vault from the cluster). Does this make sense? Using one Vault instance as a CI/CD tool for multiple clusters?
Martin Van Krieken
@mvankrieken
Oct 12 2018 13:43
@springroll12 Which cloud are you using?
springroll12
@springroll12
Oct 12 2018 13:44
we're on aws and some on-prem, so I'd like to use an infrastructure agnostic solution.
Martin Van Krieken
@mvankrieken
Oct 12 2018 13:45
ah, else you could go into the direction of https://blog.trifork.com/2018/07/20/integrating-the-aws-parameter-store-with-spring-cloud/.
Where you would integrate the AWS parameter store to hold your secrets
Martin Van Krieken
@mvankrieken
Oct 12 2018 13:51
i tried to use hashicorp vault but i could not get the high-availble setup to work like i wanted. The fact that if 1 vault went into lockdown, that i would need to ssh to every single node to unlock it manually felt like big problem in a environment where you should not be bothered where something runs
springroll12
@springroll12
Oct 12 2018 13:55
I think that is by design, for protecting your secrets. I'm not really looking at using the Vault too much in my clusters really, just as a CI/CD tool for populating cluster deployments with secrets. At least that is the way I think I understand it should be done. The alternative is to have a Vault instance (or instances) as part of each cluster, which seems like overkill for my use case and doesn't really address the CI/CD secrets management issue I'm trying to solve.
Martin Van Krieken
@mvankrieken
Oct 12 2018 13:56
Well and the overhead of heaving to manage all those different clusters and servers :P
From what i always understood, cloud config makes your backend less important. You could also use vault for your on-premise and something else for in the cloud.
Martin Van Krieken
@mvankrieken
Oct 12 2018 14:10
at the end of the day everything comes to back to what you want todo and how your setup is. The only thing you might need to keep in mind if you are going to link alot of vaults together(on-premise/cloud) is that if the design will seal all vault in a cluster, you might need to think if you really want that if a developer by accident forces 1 vault to seal, that your whole otap + production goes down by that 1 action.
besides that fact that it breaks the design that every environment should be independent
Martin Van Krieken
@mvankrieken
Oct 12 2018 14:16
@springroll12 In your case, this might also be a good read before you make a choise. https://www.infoq.com/news/2018/08/auth0-architecture-aws
springroll12
@springroll12
Oct 12 2018 14:16
Honestly the main problem I'm trying to solve is how to manage secrets in a secure way to allow continuous delivery of microservices. I'm not even sure if Vault is the right tool for that. I can't think of a use case where the secrets I would want stored in Vault would be changeable after an initial deployment. I understand that using a single vault for multiple environments is probably not the greatest, but if it is only being used for CI/CD (not relied upon for the actual deployment operations) then I think it would be ok?
@mvankrieken Good read, however I don't understand their choices. I would think it would make more sense to try to rely less on cloud platform specific services, but they went the other way. I suppose it makes more sense to do that if you are a SaaS provider.
Martin Van Krieken
@mvankrieken
Oct 12 2018 14:20
A case i can think off is if you want to use database username rotation for example
Martin Van Krieken
@mvankrieken
Oct 12 2018 14:28
@springroll12 I used to think that also and if you stand far enough away it always will seem to be a good choice, how ever the closer you get to the actual setup and connection, you will see that your are introducing alot of moving parts, just to keep everything running. These parts can then also break. For example the old but trusted vpn tunnels. They always tended to close when you did not want them too. Personally i have not encountered any company that made a choice for A cloud provider and then switched to another. For me it feels like JPA. It allows you have to connect to different databases without changing code, but how many people actually migrated their database to another database provider. For example if you are running in AWS, you probly already pulled in the aws-sdk libs for S3 and other services. Even thoo your not hard-linked to it, you will not be able to move to another Cloud provider without making changing to your app probably. If you would move to Azure for example. Keeping up with all those Cloud providers and their new features is something that will also eat up time in your development process, besides the longer testing phases.
Martin Van Krieken
@mvankrieken
Oct 12 2018 14:35
@springroll12 As a other reason people mostly say high-avaible, but if you run your setup correct and you really need to have ultimate up-time. You would run everything in multi-region. By adding another cloud to the mix, you would maybe increase that by 0.3 % but adding a lot of complexity to your application and longer build/test phases. Depending on your case, this may or may not be worth it. At least thats how i see it these days.
springroll12
@springroll12
Oct 12 2018 14:38
Not saying I disagree, but if you have a product that needs to be also deployable completely on-prem, then this is an unfortunate reality.
Martin Van Krieken
@mvankrieken
Oct 12 2018 14:42
hmm. If the requirement is that it needs to run without a connection with the internet, then you are right. Else i would probably still put my secrets into aws param-store and run a on-premise cloud-config server that connects to AWS for its environment secrets. Just like alot of people have cloud-config connect to github.