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...
General idea </a> Recently, new JUnit version has been released. I found many useful things. Besides, there’re lot’s of useless features. At least, I think something won’t be used in new JUnit version. By the way, here the new version - JUnit 5 JUnit Goal </a> It’s obvious, that JUnit decided to make their product more opensource - by releasing instruments, which will allow junit users to create lot’s of extensions Restrictions </a> JUnit 5 is running on java > 1.8 JUnit 5 has lot’s of new features, which are not working in JUnit 3 or 4. However, there is a project JUnit Vintage which allows older versions work on JUnit 5. Story about another package </a> New version has new package - org.junit.jupiter.*. This was done, mostly, for separating new version from previous versions, which completely differs. Transformations </a> All core annotation are located under org.junit.jupiter.api @Test - not this annotation comes from completely new package @TestFactory - comparing to something oldes, TestFactory is a replacement of parameterized tests @BeforeEach - new version of @Before. I wonder, why it was done. @AfterEach - new version of @After. @BeforeAll - replacement of @BeforeClass. Must be static, as usual. @AfterAll -...
