Just creating instances in the cloud is an intermediate result. Yes, you know don’t need to create them manually, but it’s not a target. We need to configure them somehow, deploy logic, restart, etc. That’s why this article is about describing how to work with Terraform instances - using Ansible tool. What do you need to do before starting Create terraform instance - here’s how Install ansible: brew install ansible How Ansible knows about Terraform Let’s take a close look how Ansible will recognize terraform instances. Normally, this is being done by specifying instances in inventory file - the idea is to have a file, which contains all the IP addresses, organized by the group. Let’s say, you have one load balancer and three instances of an application, then you need to have following inventory file: [lb] lb.example.com [app] one.example.com two.example.com three.example.com Because we are creating instances on the fly, we don’t have a predefined set of IP addresses, which we’re going to use. That’s why we should use dynamic inventory. As we’re using Terraform, we need some tool, which knows how to read instances from terraform.tfstate file and represent them to ansible. Personally, I found it useful to use...
As we are creating our instances on the fly, using Terraform declarative scripts, we can also need to create dns domains and records. Let’s say, you have two environments: dev and prod, and you you want to have your backend application stored under dev.api.myapp.com and prod.api.myapp.com. Luckily, terraform allows to do such things
Required steps
Digitalocean account
Ready and bought domain somewhere
Already defined terraform instances. See article from previous part.
Digital Ocean Domain
Add additional declaration to your terraform file:
resource "digitalocean_domain" "default" {
name = "dev.api.myapp.com"
ip_address = "${digitalocean_droplet.app-rest-api.ipv4_address}"
}
DigitalOcean Record
If you want your app to be accessible through dev.api.myapp.com, without wwwm you should add this lines:
resource "digitalocean_record" "CNAME-www" {
domain = "${digitalocean_domain.default.name}"
type = "CNAME"
name = "www"
value = "@"
}
Final Check
You should see your domain name in the list of networking domains here - https://cloud.digitalocean.com/networking/domains
On the next part we will see how to start working with cloud instances using ansible, and how to connect ansible with terraform.
Argumentation It’s not a rare examples, when people need to deploy their applications somewhere in the cloud, without having mature infrastructure, and just for testing purpose. Let’s say, you’re writing a backend part for mobile application, and your android developer needs to have backend right and now. Your actions ? Of course, create EC2/Droplet instance, scp all binaries, connect via ssh, run them. You can even write some bash script, which will do all the work. And what should you do, if some day you will decide to go live ? The same thing, you will order some instances in your favorite cloud, configure load balancer, add 1-5 instances and start running your application. But how to scale ? What, if you will decide to add couple servers, and balance them ? By the time you will need to do that, you will be the author of many scripts, which potentially have bugs. You should have something better in your arsenal. I spend couple of weeks to find an instrument, which will fit my needs, and want to share it here, in my blog. It’s not claims to be the best solution, I’m sure, there’s plenty of them, but by...
From time to time we may need to log our requests in order to get some information. Personally, I’m writing this short article, because we need to find out the reason why jackson throws 400 error status.
Luckily, it’s very easy to log your requests. Spring has a class AbstractRequestLoggingFilter, which has three concrete classes, which you can potentially use:
ServletContextRequestLoggingFilter
Log4jNestedDiagnosticContextFilter
CommonsRequestLoggingFilter
The last one is the guy we need. It’s pretty straightforward how to configure this class: just declare it in your context:
@Bean
public CommonsRequestLoggingFilter requestLoggingFilter() {
CommonsRequestLoggingFilter loggingFilter = new CommonsRequestLoggingFilter();
loggingFilter.setIncludeClientInfo(true);
loggingFilter.setIncludeQueryString(true);
loggingFilter.setIncludePayload(true);
return loggingFilter;
}
And yes, don’t forget to add additional line in your application.properties file:
logging.level.org.springframework.web.filter.CommonsRequestLoggingFilter=DEBUG
And voila, you have your requests being logged:
2016-10-24 21:50:45.520 DEBUG 83061 --- [nio-8080-exec-3] o.s.w.f.CommonsRequestLoggingFilter : Before request [uri=/api/requests;client=0:0:0:0:0:0:0:1]
... // My logs :)
2016-10-24 21:50:45.526 DEBUG 83061 --- [nio-8080-exec-3] o.s.w.f.CommonsRequestLoggingFilter : After request [uri=/api/requests;client=0:0:0:0:0:0:0:1;payload={
"title": "..."}]
Yes, it’s true, that Spring is better, than Dropwizard. I’ve worked with both frameworks, and can truly say, that Dropwizard has poor Guice dependency injection, Jersey, which I don’t like at all, and other things. But there’s one thing, which I like in Dropwizard, and which I’d be happy to see in Spring Framework - Dropwizard Metrics module. it has very rich number of instruments, which can help you to understand your application behaviour: different gauges, timers, counters, histograms, timers, and healthcheks. The question is how to import Dropwizard Metrics into Spring? Basically, you need to add 3 dependencies:one as an adapter for dropwizard metrics, another is for jvm metrics and last one for Filter, which you will use to get this metrics using http. com.ryantenney.metrics:metrics-spring:3.1.2 io.dropwizard.metrics:metrics-jvm:3.1.2 io.dropwizard.metrics:metrics-servlets:3.1.2 Depending on what build tool you have in your application - include those libraries. I use Gradle, so my build.gradle looks like following: Create Metrics Listener One thing you need to know about Dropwizard Metrics module is that it’s required to have MetricRegistry and HealthCheckRegistry classes to be instantiated under ServletContext. That’s why we’ll get it from constructor, and initialise context. We will create a separate bean for this listener soon. Creating...
