Deploying and operating GeoServer: a DevOps perspective
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Parma, Alessandro
In this presentation we will share with you the lessons we have learned at GeoSolutions when deploying and operating GeoServer as well as some common patterns for the migration of on premise GeoServer clusters to the cloud. We'll share with you tips on how to: - best practices to migrate your existing GeoServer cluster to the cloud - insights on your geoserver cluster using centralized logging and Monitor plugin - avoid common bottlenecks to best set up a distributed scalable GeoServer cluster - work containers and container orchestrators like Kubernetes Cloud computing is revolutionizing the way companies develop, deploy and operate software and GeoSpatial software is no exception. With benefits of cloud based deployments range from cost savings to simplified management, flexibility, lower downtime and scalability of dynamic environments it is easy to understand why more and more companies are migrating their on premise systems to the cloud but cloud based setups have their own set of hurdles and challenges. The migration of the series itself can be challenging. Monitoring, debugging and scaling of applications are very much different than what you are used to.
 Hello, everybody. The next presentation is about geo-server and you have Lissando Parma to talk about this. He is a senior DevOps engineer at GeoSolutions. He designs and implements GeoSpecial Systems based on geo-server and other great open source projects. Hello, Alessandro. Hi Diego, can you hear me? Yes. Right. Thanks for the nice introduction. My name is Alessandro Parma. I work at GeoSolutions as a DevOps engineer as Diego said. Today we're going to talk about geo-server specifically, about how to deploy and operate geo-servers from a DevOps perspective. It's going to be cloud-oriented. So we're going to talk a bit about cloud deployments and how to migrate your GeoServer cluster to the cloud. Two words about GeoSolutions, the company that I work for. We're based in Italy and the US and we have worldwide clients. We comprise of more than 30 collaborators and 25 engineers. Some of the products we work with are listed here, GeoServer, MapStore, GeoNode, GeoNetwork. We offer support services, enterprise support services, deployment solutions, so we can help out with your deployments, customized solutions, so of course you can reach out for help with development and professional trainings as well on all of the products listed above. We support affiliations, so we support strongly open source, as you can tell by the list of products we work with. We collaborate and participate in many working groups, including OSGeo, OGC and USGIF. Okay, let's jump into the presentation. Here's the agenda, so what we're going to talk about in detail. Cloud computing, we're going to give a brief intro, just the terminology so that you can understand what we're talking about in case you don't know yet. Might may be relevant to you, so without the pros and cons of moving to the cloud, why you should be considering using the cloud if you're not yet using clouds and the migration process. So if you're interested in it, we're going to talk about migrating to the cloud in general as well as specifically for your GeoServer, so you may be thinking about migrating your GeoServer cluster from a non-premise to the cloud, we're going to talk about that. We're going to check what are the common pitfalls as well as give you some tips gained from our experience. We're going to talk as well about containers, orchestrators and specifically Kubernetes, which is quite relevant I think. Nowadays it's gaining more and more popularity and you could benefit from deploying your GeoServer in a Kubernetes orchestrator, why? And then two words about monitoring and logging, it's a bit different in the cloud compared to traditional deployment, so we're going to talk about that as well as how to gain insights from your GeoServer cluster. So cloud computing, what is cloud computing? Basically means computing services over the internet, so servers, storage, databases, networks, software, whatever, every kind of service or resource that is offered to you by a provider over the internet. That's supposed to hosting your own thing with your own hardware that you bought locally. And there are several pros and cons that we can talk about in terms of cloud computing. Some of the pros, the big pros of cloud computing are often mentioned elasticity, so the ability to adapt to the workload changes by provisioning and deprovisioning resources on demand. So at the time the load increases, you'd be provisioning more resources, when the load goes down, you'd be decommissioning resources. For example, this would be AWS EC2, if you're familiar with AWS or similar, an auto scaling group, so you could shrink and enlarge your EC2 instances pool based on load, for instance. Another typical example would be elastic storage, so you can get some storage from a cloud provider and it will adapt based on the amount of this space you need. Another pro of cloud computing is scalability. So some of these services provided by cloud providers can change and allocate more resources depending on the need of your application. So let's say the Vito Machine, you can change the type of Vito Machine based on the amount of core or RAM that you need, or scaling a database based on the load that your application, your own application is demanding from the database. Another pro of cloud computing, reduce time to market, so especially relevant for business and management, if you think about IIS, so infrastructure as a service, for instance, you can ask for Vito Machines, databases, whatever to the cloud provider and they're immediately available to you. You don't have to put down the money, get your own infrastructure, get your own engineers and so on, so significantly shorter time to market. Security and privacy maybe could be considered a con of using cloud services. You're using cloud services, you're basically moving your local application and resources to the cloud where they may be running along other services by other providers, so you need to be aware of that. Your applications may be running on a server that is used by other people and there are some security and privacy concerns following that. The pro would be lower costs, so you can significantly reduce the costs of hosting your applications when you move to the cloud, especially if you leverage the elasticity of cloud services. So if you pay attention to scale and book resources depending on the load of the system, then it can lead to a significant reduce of cost. If you just book a ton of resources from the cloud provider without adapting it to the load over time, it can increase the cost of hosting your services because they're not cheap usually. There are a few different deployment models in the cloud. You have public cloud, which is the most widely used cloud deployment model. Its cost effective is what I was saying before, so the cloud provider is making the infrastructure available to you and other people, other companies to run their software. They're all running on the same infrastructure. Then we have private cloud. Private cloud is basically a dedicated cloud infrastructure for your organization or for yourself. It can be quite costly and it's usually reserved to people working for government or schools or agency or other environments where you need absolutely secure environments and you're dealing sensitive data. So in the private cloud you're isolated from other services, no other people is using the infrastructure, so it can be considered safer in terms of security and privacy. Then we have hybrid cloud. Hybrid cloud is a mix of the two. Mix of the two is a combination of public with a private environment. That's typically implemented with restricting at the networking level the access and the communication between the services. So your application is running next to other applications, but they're not allowed to talk to your applications. So this is kind of combines the benefits of the two. Right, let's talk about moving geo server to the cloud. So we talked about the cloud, a brief introduction. Now we're going to talk about how you could migrate your local cluster to the cloud. There are a few methodologies. First one is rehost or also known as lift and shift. It's an IAS approach, so infrastructure as a service approach. You're booking the resources from the provider and you're redeploying the application stack yourself without basically changing anything. So you're booking your virtual machines and then deploying yourself the applications just like you would do on your local on-premise environment. In this scenario you're not really leveraging all the services offered by the provider, so managed service like databases or other kind of storage service for instance. You're just taking your local environment and uploading it to the cloud. It's a relatively easy thing to do, so it's quite common pattern as well. The other approach would be refactor or lift, tinker and shift. In this scenario you tweak a bit your architecture and adapt it to the cloud, to the environment where it's deployed on. This would be a pass approach, so platform as a service approach. You're still booking the resources from the provider, but then you're also using some of the services offered by the provider. An example would be a managed database, so you're not using the standard self-provision database, you're using one of the providers. Finally, revise or build and replace, that's a more expensive approach in terms of resources and time. You would basically rewrite your application to leverage all the services available. This requires quite a lot of fore-planning and knowledge to be implemented. As we were saying, rehost means taking your local resources and moving them to the cloud. How would you do that in a practical term? You need to choose the right kind of virtual machines. For a geoserver that would be a compute optimized virtual machine. So, geoserver likes fast CPU cores. As a rule of thumb, you can get four core virtual machines with four gigabytes of RAM, for instance, and redeploy to the cluster. You would migrate the instances, configure your application, upload your data and you're done. That would be the rehost approach. Refactor, use some of the services of the provider. As we said, manage database has quite a lot of advantages in my opinion. You can use backup and restore features. You can use snapshots, auto upgrades and so on. So, there are quite a lot of nice things that you don't need to worry about. You can leverage some of the storage options provided to you. You need to be careful on the kind of storage that you use for each component of your application. For geoserver that means you need to choose the right storage for data dear, cache, data files and so on. By the way, also, COGS are supported by geoserver. In that case, you would be leveraging some object storage offered by the provider. You can think about storage cache styles in the object storage too. Here's a small diagram of geoserver cluster deployed in EKS. So, Kubernetes as a service offered by AWS is a typical layout of how you could do it and the kind of storage that you can use for each one of the components we were talking before. FileShare, which is basically an NFS, you could use it for spatial data. So to share spatial data between the instances and you could think about using it for cache styles for instance. Has a couple of advantages. Of course, it's a shared file system. So all of the instances distributed across the nodes can use it and it scales pretty well. Block storage would be your regular local storage. It's not shared. So you shouldn't be using it for data, for instance, if you want it to be available to all the instances. Benefits low latency. So it's good fit for temporary storing files like audit files and log files. Maybe cache styles. In that case, you would have a non-shared cache between your instances, your geoserver cluster. So there are some implications about that. So unless you really need very, very low latency, I wouldn't use it for cache styles. Finally, block storage, block storage services like AWS S3 brings a ton of scalability. They scale pretty much indefinitely. It's cheap. So it's good to store lots of data. And it's shared again. So you could think about using it for cache styles, for instance, or cogs. So a quick recap. Small checklist basically about things to consider for a cloud migration, go for computer oriented instances of geoserver, choose a migration strategy, either lift and shift or refactor, consider using services offered by the provider like manage databases, and pick the right storage for the purpose and the needs of your project. Here's another topic that is linked to the previous one to Kubernetes. You can also use Helm to deploy your geoserver cluster. There are some details here. It's basically a package manager for Kubernetes. So it easily packages all of your software into a set of files that you can deploy in your Kubernetes cluster, allowing you to kind of template them and adapting to your environment. So it's a pretty nice tool. I advise you check it out. There are some resources available on the internet, like Docker images. You can find the links in here. And the Helm chart is coming too as well. So we're working on it. Keep an eye on our blog and you will find an update over there. There's also free webinar. If you're interested in running geoserver on Kubernetes specifically, that we, I hosted about a month ago, it's available for you to take a look at. Two words about logging and monitoring real quick. So it can be tricky in a cloud environment to keep an eye on everything. The environment is pretty much dynamic and distributed. So you have instances starting and stopping. You have distributed instances of your application across nodes. So it can be hard to identify and debug problems in this environment. We have some tips for you. So you should consider aggregating and centralizing all the logs to a single location. That is easy to navigate and filter. So you don't have to go around all your nodes and to check out the logs of the application. Keep in mind that nodes can spawn and also go away. So a node can die if you keep your logs on a specific node and you don't ship it over to a central location, you run the risk of losing it. And set up shippers to collect and send out the logs to the central service. But metrics, of course, very important. There are performance indicators like response time throughput, uptime error rate and so on. And auditing. Auditing is a nice feature offered by an extension. GeoServer extension called monitor. It basically tracks requests made to GeoServer and export the information about these requests into audit logs. Adlocks that you can collect and ingest and create pretty dashboards from. Here you can see an audit event example, the kind of information you have in it, performance layer errors and so on. And here's an example of a small dashboard with performance-related information that you can look at. Things like response time, slow layers, cache hits or miss and so on. A few more examples. Response time, IP of the requesters and so on. And finally, auditing. So remember to set up audits for your services. So you're checking the services being up and down, you're checking for errors, error rates, auto memory errors and so on. Remember to use different channels depending on the severity of the problem. So if it's a problem that needs immediate attention, then you should consider paging someone. If it's a less severe problem, maybe you can just send out an email and avoid waking someone in the middle of the night. That would be nice. And then you can think about automating the fix to the problem. So you can put in place some scripts and tools to try to fix the problem for you without waking up anyone. Examples of these would be watchdogs and health checks. So you're kind of probing the service and checking the response just to make sure it's healthy and eventually restart it if needed. Here you can find some useful links about what I've been talking about. The juice solutions website, the webinars, cloud optimized geotifs and health. And that's all I had Diego. So I think if there's any question for me. A moment, yes, I have some questions. The first one is, where can the dashboards with data from audit logs be viewed? So it's a web application. The one specifically the one that I was showing you is part of a stack of applications by Elastic, the X-Tac. It's a web-based application called Kibana. So you can access it from the Internet easily. And you'll find all the dashboards and visualizations. The ones that I showed you are just a subset, of course. There's a lot of things that you can do and information that you can view depending on what you're interested in. So it could be business related information, some analytics for managers or people that want to know how the service is being used or could be metrics, logs for operations and so on. Okay, another one is how to use log data to tune the application. Do you have any use cases to simplify? Yes, that's a nice question. If we're talking about audit files, for instance, the kind of information you have in them can be very relevant if you're looking for improvements in terms of performance. So you can extract information for audit files about caching, for instance. So you can realize that you're not leveraging the cache as much as you think and try to change things. So take a look at your client application if it's not configured properly to use the cache, for instance. Or you can find some outliers. So you can be very fine grained with these tools and find slow requests and from them try to reverse engineer and try to understand why they're being that slow and then fix the layer. Maybe it's a configuration issue, maybe it's a styling issue. So yeah, it can definitely be used, I would use Kibana for that. Okay, another one. What storage is recommended for J-Web cache? Can you make use of S3 as a blob storage for the cache? Yeah, yeah, yeah, that's another good question. There's no definitive answer, so it really depends on your use case. S3 can be used by means of a plugin available for your server. So GWCS3 plugin allows you to store cache tiles in S3 and that would give you a very good scalability. So you would be able to support a ton of requests per second thanks to the scalability of the S3 service itself. There are other options of course, a file share like an NFS or similar, you can use to share the cache tiles between all your instances. Maybe it would have a lower latency in that case, so in terms of pure performance would be a bit faster. But it can be a bottleneck if you have a very, very high load on your system. So if you're serving many, many requests. There's, it's possible to use the memory cache of API gateway in front of the JOSERV. It's my question. Not that I'm aware of, I may be missing something, but I'm not aware of any way to use it directly from JOSERV. Another one is JOSERV. Kubernetes is a great competition to the classical ArchG Serves. Have you also helped clients to move from AGS to JOSERV and make the revised, rebuilt approach? Yes, yes, that's something we have done a few times with different clients already. And we keep posting regularly in our blog about useful information on how to ease the transition. So if you head over to the blog, you will find some relevant blog posts about the topic. And yeah, that's something we can do. We can help out with revising and migrating your cluster to the cloud. Okay, more one. When should I consider distributed JOSERV? Is there a threshold of that usage where it is optimal? Should I consider just sharding the data source and keep a single JOSERV node? Yeah, another very good question. So if you're running a single instance of JOSERV, no matter how good is your data store and how scalable it is, at some point you will hit a bottleneck, either at the machine level, operating system level, or in the JOSERV code itself. So that's why it's useful for production systems and systems that have high load to be able to scale out. And you would need to set up more JOSERV instances to overcome these kind of limitations, especially distributed across multiple nodes, that way they would not compete for resources on the same node, for instance, CPU. They would not try to get all the CPU to steal it from each other. Okay. Thanks. Thanks, Alessandro. There is no more questions. Would you like to talk more, anything? Thank you. I don't know. We have the contact info in the slides that I've shared before. If you have any questions, any more questions, you can reach out to us using that contact information or head over to our website. We keep publishing interesting things in our blogs. Okay. You have more? One question. Yeah. Is it advisable to use a single DWC in front of a scalable cluster of JOSERV nodes? Okay. So, good question. It wouldn't be highly available. So if you set up a cluster of JOSERV nodes so that they are highly available, in case one of them dies, if you set up a single DWC instance in front of JOSERV, then you're creating a single point of failure again. So, if that node goes down, then your service goes down. And that's not good. We typically recommend using the integrated J-Web cache into JOSERV without setting up a dedicated node in front of them. Okay. It's the last. I would like to thank all the presenters and the audience. And it's the end of the day for us. And see you all tomorrow. Okay. Bye-bye. Thank you all. Thank you. Bye-bye. Bye-bye. Bye-bye. Bye-bye.
 Hello, everybody.  The next presentation is about geo-server and you have Lissando Parma to talk about this.  He is a senior DevOps engineer at GeoSolutions.  He designs and implements GeoSpecial Systems based on geo-server and other great open source  projects.  Hello, Alessandro.  Hi Diego, can you hear me?  Yes.  Right.  Thanks for the nice introduction.  My name is Alessandro Parma.  I work at GeoSolutions as a DevOps engineer as Diego said.  Today we're going to talk about geo-server specifically, about how to deploy and operate  geo-servers from a DevOps perspective.  It's going to be cloud-oriented.  So we're going to talk a bit about cloud deployments and how to migrate your GeoServer cluster  to the cloud.  Two words about GeoSolutions, the company that I work for.  We're based in Italy and the US and we have worldwide clients.  We comprise of more than 30 collaborators and 25 engineers.  Some of the products we work with are listed here, GeoServer, MapStore, GeoNode, GeoNetwork.  We offer support services, enterprise support services, deployment solutions, so we can  help out with your deployments, customized solutions, so of course you can reach out  for help with development and professional trainings as well on all of the products listed  above.  We support affiliations, so we support strongly open source, as you can tell by the list of  products we work with.  We collaborate and participate in many working groups, including OSGeo, OGC and USGIF.  Okay, let's jump into the presentation.  Here's the agenda, so what we're going to talk about in detail.  Cloud computing, we're going to give a brief intro, just the terminology so that you can  understand what we're talking about in case you don't know yet.  Might may be relevant to you, so without the pros and cons of moving to the cloud, why  you should be considering using the cloud if you're not yet using clouds and the migration  process.  So if you're interested in it, we're going to talk about migrating to the cloud in general  as well as specifically for your GeoServer, so you may be thinking about migrating your  GeoServer cluster from a non-premise to the cloud, we're going to talk about that.  We're going to check what are the common pitfalls as well as give you some tips gained from  our experience.  We're going to talk as well about containers, orchestrators and specifically Kubernetes,  which is quite relevant I think.  Nowadays it's gaining more and more popularity and you could benefit from deploying your  GeoServer in a Kubernetes orchestrator, why?  And then two words about monitoring and logging, it's a bit different in the cloud compared  to traditional deployment, so we're going to talk about that as well as how to gain insights  from your GeoServer cluster.  So cloud computing, what is cloud computing?  Basically means computing services over the internet, so servers, storage, databases,  networks, software, whatever, every kind of service or resource that is offered to you  by a provider over the internet.  That's supposed to hosting your own thing with your own hardware that you bought locally.  And there are several pros and cons that we can talk about in terms of cloud computing.  Some of the pros, the big pros of cloud computing are often mentioned elasticity, so the ability  to adapt to the workload changes by provisioning and deprovisioning resources on demand.  So at the time the load increases, you'd be provisioning more resources, when the load  goes down, you'd be decommissioning resources.  For example, this would be AWS EC2, if you're familiar with AWS or similar, an auto scaling  group, so you could shrink and enlarge your EC2 instances pool based on load, for instance.  Another typical example would be elastic storage, so you can get some storage from a cloud provider  and it will adapt based on the amount of this space you need.  Another pro of cloud computing is scalability.  So some of these services provided by cloud providers can change and allocate more resources  depending on the need of your application.  So let's say the Vito Machine, you can change the type of Vito Machine based on the amount  of core or RAM that you need, or scaling a database based on the load that your application,  your own application is demanding from the database.  Another pro of cloud computing, reduce time to market, so especially relevant for business  and management, if you think about IIS, so infrastructure as a service, for instance,  you can ask for Vito Machines, databases, whatever to the cloud provider and they're  immediately available to you.  You don't have to put down the money, get your own infrastructure, get your own engineers  and so on, so significantly shorter time to market.  Security and privacy maybe could be considered a con of using cloud services.  You're using cloud services, you're basically moving your local application and resources  to the cloud where they may be running along other services by other providers, so you  need to be aware of that.  Your applications may be running on a server that is used by other people and there are  some security and privacy concerns following that.  The pro would be lower costs, so you can significantly reduce the costs of hosting your applications  when you move to the cloud, especially if you leverage the elasticity of cloud services.  So if you pay attention to scale and book resources depending on the load of the system,  then it can lead to a significant reduce of cost.  If you just book a ton of resources from the cloud provider without adapting it to the  load over time, it can increase the cost of hosting your services because they're not  cheap usually.  There are a few different deployment models in the cloud.  You have public cloud, which is the most widely used cloud deployment model.  Its cost effective is what I was saying before, so the cloud provider is making the infrastructure  available to you and other people, other companies to run their software.  They're all running on the same infrastructure.  Then we have private cloud.  Private cloud is basically a dedicated cloud infrastructure for your organization or for  yourself.  It can be quite costly and it's usually reserved to people working for government or schools  or agency or other environments where you need absolutely secure environments and you're  dealing sensitive data.  So in the private cloud you're isolated from other services, no other people is using the  infrastructure, so it can be considered safer in terms of security and privacy.  Then we have hybrid cloud.  Hybrid cloud is a mix of the two.  Mix of the two is a combination of public with a private environment.  That's typically implemented with restricting at the networking level the access and the  communication between the services.  So your application is running next to other applications, but they're not allowed to talk  to your applications.  So this is kind of combines the benefits of the two.  Right, let's talk about moving geo server to the cloud.  So we talked about the cloud, a brief introduction.  Now we're going to talk about how you could migrate your local cluster to the cloud.  There are a few methodologies.  First one is rehost or also known as lift and shift.  It's an IAS approach, so infrastructure as a service approach.  You're booking the resources from the provider and you're redeploying the application stack  yourself without basically changing anything.  So you're booking your virtual machines and then deploying yourself the applications  just like you would do on your local on-premise environment.  In this scenario you're not really leveraging all the services offered by the provider,  so managed service like databases or other kind of storage service for instance.  You're just taking your local environment and uploading it to the cloud.  It's a relatively easy thing to do, so it's quite common pattern as well.  The other approach would be refactor or lift, tinker and shift.  In this scenario you tweak a bit your architecture and adapt it to the cloud, to the environment  where it's deployed on.  This would be a pass approach, so platform as a service approach.  You're still booking the resources from the provider, but then you're also using some  of the services offered by the provider.  An example would be a managed database, so you're not using the standard self-provision  database, you're using one of the providers.  Finally, revise or build and replace, that's a more expensive approach in terms of resources  and time.  You would basically rewrite your application to leverage all the services available.  This requires quite a lot of fore-planning and knowledge to be implemented.  As we were saying, rehost means taking your local resources and moving them to the cloud.  How would you do that in a practical term?  You need to choose the right kind of virtual machines.  For a geoserver that would be a compute optimized virtual machine.  So, geoserver likes fast CPU cores.  As a rule of thumb, you can get four core virtual machines with four gigabytes of RAM,  for instance, and redeploy to the cluster.  You would migrate the instances, configure your application, upload your data and you're  done.  That would be the rehost approach.  Refactor, use some of the services of the provider.  As we said, manage database has quite a lot of advantages in my opinion.  You can use backup and restore features.  You can use snapshots, auto upgrades and so on.  So, there are quite a lot of nice things that you don't need to worry about.  You can leverage some of the storage options provided to you.  You need to be careful on the kind of storage that you use for each component of your application.  For geoserver that means you need to choose the right storage for data dear, cache, data  files and so on.  By the way, also, COGS are supported by geoserver.  In that case, you would be leveraging some object storage offered by the provider.  You can think about storage cache styles in the object storage too.  Here's a small diagram of geoserver cluster deployed in EKS.  So, Kubernetes as a service offered by AWS is a typical layout of how you could do it  and the kind of storage that you can use for each one of the components we were talking  before.  FileShare, which is basically an NFS, you could use it for spatial data.  So to share spatial data between the instances and you could think about using it for cache  styles for instance.  Has a couple of advantages.  Of course, it's a shared file system.  So all of the instances distributed across the nodes can use it and it scales pretty  well.  Block storage would be your regular local storage.  It's not shared.  So you shouldn't be using it for data, for instance, if you want it to be available to  all the instances.  Benefits low latency.  So it's good fit for temporary storing files like audit files and log files.  Maybe cache styles.  In that case, you would have a non-shared cache between your instances, your geoserver  cluster.  So there are some implications about that.  So unless you really need very, very low latency, I wouldn't use it for cache styles.  Finally, block storage, block storage services like AWS S3 brings a ton of scalability.  They scale pretty much indefinitely.  It's cheap.  So it's good to store lots of data.  And it's shared again.  So you could think about using it for cache styles, for instance, or cogs.  So a quick recap.  Small checklist basically about things to consider for a cloud migration, go for computer  oriented instances of geoserver, choose a migration strategy, either lift and shift or  refactor, consider using services offered by the provider like manage databases, and  pick the right storage for the purpose and the needs of your project.  Here's another topic that is linked to the previous one to Kubernetes.  You can also use Helm to deploy your geoserver cluster.  There are some details here.  It's basically a package manager for Kubernetes.  So it easily packages all of your software into a set of files that you can deploy in  your Kubernetes cluster, allowing you to kind of template them and adapting to your environment.  So it's a pretty nice tool.  I advise you check it out.  There are some resources available on the internet, like Docker images.  You can find the links in here.  And the Helm chart is coming too as well.  So we're working on it.  Keep an eye on our blog and you will find an update over there.  There's also free webinar.  If you're interested in running geoserver on Kubernetes specifically, that we, I hosted  about a month ago, it's available for you to take a look at.  Two words about logging and monitoring real quick.  So it can be tricky in a cloud environment to keep an eye on everything.  The environment is pretty much dynamic and distributed.  So you have instances starting and stopping.  You have distributed instances of your application across nodes.  So it can be hard to identify and debug problems in this environment.  We have some tips for you.  So you should consider aggregating and centralizing all the logs to a single location.  That is easy to navigate and filter.  So you don't have to go around all your nodes and to check out the logs of the application.  Keep in mind that nodes can spawn and also go away.  So a node can die if you keep your logs on a specific node and you don't ship it over  to a central location, you run the risk of losing it.  And set up shippers to collect and send out the logs to the central service.  But metrics, of course, very important.  There are performance indicators like response time throughput, uptime error rate and so on.  And auditing.  Auditing is a nice feature offered by an extension.  GeoServer extension called monitor.  It basically tracks requests made to GeoServer and export the information about these requests  into audit logs.  Adlocks that you can collect and ingest and create pretty dashboards from.  Here you can see an audit event example, the kind of information you have in it, performance  layer errors and so on.  And here's an example of a small dashboard with performance-related information that  you can look at.  Things like response time, slow layers, cache hits or miss and so on.  A few more examples.  Response time, IP of the requesters and so on.  And finally, auditing.  So remember to set up audits for your services.  So you're checking the services being up and down, you're checking for errors, error rates,  auto memory errors and so on.  Remember to use different channels depending on the severity of the problem.  So if it's a problem that needs immediate attention, then you should consider paging  someone.  If it's a less severe problem, maybe you can just send out an email and avoid waking someone  in the middle of the night.  That would be nice.  And then you can think about automating the fix to the problem.  So you can put in place some scripts and tools to try to fix the problem for you without  waking up anyone.  Examples of these would be watchdogs and health checks.  So you're kind of probing the service and checking the response just to make sure it's  healthy and eventually restart it if needed.  Here you can find some useful links about what I've been talking about.  The juice solutions website, the webinars, cloud optimized geotifs and health.  And that's all I had Diego.  So I think if there's any question for me.  A moment, yes, I have some questions.  The first one is, where can the dashboards with data from audit logs be viewed?  So it's a web application.  The one specifically the one that I was showing you is part of a stack of applications by  Elastic, the X-Tac.  It's a web-based application called Kibana.  So you can access it from the Internet easily.  And you'll find all the dashboards and visualizations.  The ones that I showed you are just a subset, of course.  There's a lot of things that you can do and information that you can view depending on  what you're interested in.  So it could be business related information, some analytics for managers or people that  want to know how the service is being used or could be metrics, logs for operations and  so on.  Okay, another one is how to use log data to tune the application.  Do you have any use cases to simplify?  Yes, that's a nice question.  If we're talking about audit files, for instance, the kind of information you have in them can  be very relevant if you're looking for improvements in terms of performance.  So you can extract information for audit files about caching, for instance.  So you can realize that you're not leveraging the cache as much as you think and try to  change things.  So take a look at your client application if it's not configured properly to use the  cache, for instance.  Or you can find some outliers.  So you can be very fine grained with these tools and find slow requests and from them  try to reverse engineer and try to understand why they're being that slow and then fix the  layer.  Maybe it's a configuration issue, maybe it's a styling issue.  So yeah, it can definitely be used, I would use Kibana for that.  Okay, another one.  What storage is recommended for J-Web cache?  Can you make use of S3 as a blob storage for the cache?  Yeah, yeah, yeah, that's another good question.  There's no definitive answer, so it really depends on your use case.  S3 can be used by means of a plugin available for your server.  So GWCS3 plugin allows you to store cache tiles in S3 and that would give you a very good  scalability.  So you would be able to support a ton of requests per second thanks to the scalability  of the S3 service itself.  There are other options of course, a file share like an NFS or similar, you can use  to share the cache tiles between all your instances.  Maybe it would have a lower latency in that case, so in terms of pure performance would  be a bit faster.  But it can be a bottleneck if you have a very, very high load on your system.  So if you're serving many, many requests.  There's, it's possible to use the memory cache of API gateway in front of the JOSERV.  It's my question.  Not that I'm aware of, I may be missing something, but I'm not aware of any way to use it directly  from JOSERV.  Another one is JOSERV.  Kubernetes is a great competition to the classical ArchG Serves.  Have you also helped clients to move from AGS to JOSERV and make the revised, rebuilt  approach?  Yes, yes, that's something we have done a few times with different clients already.  And we keep posting regularly in our blog about useful information on how to ease the  transition.  So if you head over to the blog, you will find some relevant blog posts about the topic.  And yeah, that's something we can do.  We can help out with revising and migrating your cluster to the cloud.  Okay, more one.  When should I consider distributed JOSERV?  Is there a threshold of that usage where it is optimal?  Should I consider just sharding the data source and keep a single JOSERV node?  Yeah, another very good question.  So if you're running a single instance of JOSERV, no matter how good is your data store  and how scalable it is, at some point you will hit a bottleneck, either at the machine  level, operating system level, or in the JOSERV code itself.  So that's why it's useful for production systems and systems that have high load to be able  to scale out.  And you would need to set up more JOSERV instances to overcome these kind of limitations, especially  distributed across multiple nodes, that way they would not compete for resources on the  same node, for instance, CPU.  They would not try to get all the CPU to steal it from each other.  Okay.  Thanks.  Thanks, Alessandro.  There is no more questions.  Would you like to talk more, anything?  Thank you.  I don't know.  We have the contact info in the slides that I've shared before.  If you have any questions, any more questions, you can reach out to us using that contact  information or head over to our website.  We keep publishing interesting things in our blogs.  Okay.  You have more?  One question.  Yeah.  Is it advisable to use a single DWC in front of a scalable cluster of JOSERV nodes?  Okay.  So, good question.  It wouldn't be highly available.  So if you set up a cluster of JOSERV nodes so that they are highly available, in case  one of them dies, if you set up a single DWC instance in front of JOSERV, then you're  creating a single point of failure again.  So, if that node goes down, then your service goes down.  And that's not good.  We typically recommend using the integrated J-Web cache into JOSERV without setting up  a dedicated node in front of them.  Okay.  It's the last.  I would like to thank all the presenters and the audience.  And it's the end of the day for us.  And see you all tomorrow.  Okay.  Bye-bye.  Thank you all.  Thank you.  Bye-bye.  Bye-bye.  Bye-bye.  Bye-bye.
FOSS4G_-_Deploying_and_operating_GeoServer__a_DevO_zqrTIcxJEJk_0_131.png FOSS4G_-_Deploying_and_operating_GeoServer__a_DevO_zqrTIcxJEJk_132_179.png FOSS4G_-_Deploying_and_operating_GeoServer__a_DevO_zqrTIcxJEJk_180_227.png FOSS4G_-_Deploying_and_operating_GeoServer__a_DevO_zqrTIcxJEJk_228_1331.png FOSS4G_-_Deploying_and_operating_GeoServer__a_DevO_zqrTIcxJEJk_1332_2315.png FOSS4G_-_Deploying_and_operating_GeoServer__a_DevO_zqrTIcxJEJk_2316_3767.png FOSS4G_-_Deploying_and_operating_GeoServer__a_DevO_zqrTIcxJEJk_3768_4355.png FOSS4G_-_Deploying_and_operating_GeoServer__a_DevO_zqrTIcxJEJk_4356_4571.png FOSS4G_-_Deploying_and_operating_GeoServer__a_DevO_zqrTIcxJEJk_4572_7055.png FOSS4G_-_Deploying_and_operating_GeoServer__a_DevO_zqrTIcxJEJk_7056_7199.png FOSS4G_-_Deploying_and_operating_GeoServer__a_DevO_zqrTIcxJEJk_7200_16895.png FOSS4G_-_Deploying_and_operating_GeoServer__a_DevO_zqrTIcxJEJk_16896_17291.png FOSS4G_-_Deploying_and_operating_GeoServer__a_DevO_zqrTIcxJEJk_17292_23171.png FOSS4G_-_Deploying_and_operating_GeoServer__a_DevO_zqrTIcxJEJk_23172_23855.png FOSS4G_-_Deploying_and_operating_GeoServer__a_DevO_zqrTIcxJEJk_23856_27395.png FOSS4G_-_Deploying_and_operating_GeoServer__a_DevO_zqrTIcxJEJk_27396_29147.png FOSS4G_-_Deploying_and_operating_GeoServer__a_DevO_zqrTIcxJEJk_29148_29279.png FOSS4G_-_Deploying_and_operating_GeoServer__a_DevO_zqrTIcxJEJk_29280_30971.png FOSS4G_-_Deploying_and_operating_GeoServer__a_DevO_zqrTIcxJEJk_30972_31271.png FOSS4G_-_Deploying_and_operating_GeoServer__a_DevO_zqrTIcxJEJk_31272_31883.png FOSS4G_-_Deploying_and_operating_GeoServer__a_DevO_zqrTIcxJEJk_31884_32219.png FOSS4G_-_Deploying_and_operating_GeoServer__a_DevO_zqrTIcxJEJk_32220_32615.png FOSS4G_-_Deploying_and_operating_GeoServer__a_DevO_zqrTIcxJEJk_32616_32819.png FOSS4G_-_Deploying_and_operating_GeoServer__a_DevO_zqrTIcxJEJk_32820_35159.png FOSS4G_-_Deploying_and_operating_GeoServer__a_DevO_zqrTIcxJEJk_35160_35591.png FOSS4G_-_Deploying_and_operating_GeoServer__a_DevO_zqrTIcxJEJk_35592_35699.png FOSS4G_-_Deploying_and_operating_GeoServer__a_DevO_zqrTIcxJEJk_35700_35783.png FOSS4G_-_Deploying_and_operating_GeoServer__a_DevO_zqrTIcxJEJk_35784_36335.png FOSS4G_-_Deploying_and_operating_GeoServer__a_DevO_zqrTIcxJEJk_36336_36527.png FOSS4G_-_Deploying_and_operating_GeoServer__a_DevO_zqrTIcxJEJk_36528_36587.png FOSS4G_-_Deploying_and_operating_GeoServer__a_DevO_zqrTIcxJEJk_36588_37427.png FOSS4G_-_Deploying_and_operating_GeoServer__a_DevO_zqrTIcxJEJk_37428_38315.png FOSS4G_-_Deploying_and_operating_GeoServer__a_DevO_zqrTIcxJEJk_38316_38687.png FOSS4G_-_Deploying_and_operating_GeoServer__a_DevO_zqrTIcxJEJk_38688_38795.png FOSS4G_-_Deploying_and_operating_GeoServer__a_DevO_zqrTIcxJEJk_38796_40103.png FOSS4G_-_Deploying_and_operating_GeoServer__a_DevO_zqrTIcxJEJk_40104_41243.png FOSS4G_-_Deploying_and_operating_GeoServer__a_DevO_zqrTIcxJEJk_41244_41567.png FOSS4G_-_Deploying_and_operating_GeoServer__a_DevO_zqrTIcxJEJk_41568_42179.png FOSS4G_-_Deploying_and_operating_GeoServer__a_DevO_zqrTIcxJEJk_42180_43883.png FOSS4G_-_Deploying_and_operating_GeoServer__a_DevO_zqrTIcxJEJk_43884_43967.png FOSS4G_-_Deploying_and_operating_GeoServer__a_DevO_zqrTIcxJEJk_43968_44903.png FOSS4G_-_Deploying_and_operating_GeoServer__a_DevO_zqrTIcxJEJk_44904_45011.png FOSS4G_-_Deploying_and_operating_GeoServer__a_DevO_zqrTIcxJEJk_45012_45107.png FOSS4G_-_Deploying_and_operating_GeoServer__a_DevO_zqrTIcxJEJk_45108_45731.png FOSS4G_-_Deploying_and_operating_GeoServer__a_DevO_zqrTIcxJEJk_45732_45887.png FOSS4G_-_Deploying_and_operating_GeoServer__a_DevO_zqrTIcxJEJk_45888_46679.png FOSS4G_-_Deploying_and_operating_GeoServer__a_DevO_zqrTIcxJEJk_46680_46727.png FOSS4G_-_Deploying_and_operating_GeoServer__a_DevO_zqrTIcxJEJk_46728_48875.png FOSS4G_-_Deploying_and_operating_GeoServer__a_DevO_zqrTIcxJEJk_48876_49091.png FOSS4G_-_Deploying_and_operating_GeoServer__a_DevO_zqrTIcxJEJk_49092_49451.png FOSS4G_-_Deploying_and_operating_GeoServer__a_DevO_zqrTIcxJEJk_49452_49565.png