Publishing Existing Repo to New Location

Let’s say you fork a public open source repo to your laptop, then decide you’re ready to publish it to your own repository.

So if I clone a public repo:

➜ git clone https://github.com/sedkis/auth-plugin
clone complete
➜ git remote -v
origin	git@github.com:sedkis/auth-plugin.git (fetch)
origin	git@github.com:sedkis/auth-plugin.git (push)

It’s pointing at the old repo. If I’m ready to publish this repo to another host, then first I create my new repo on GitHub (or wherever), then change git origin to it and push:

➜ git remote rm origin
➜ git remote add origin git@github.com:new-origin/auth-plugin.git
➜ git remote -v
origin	git@github.com:your-repo/auth-plugin.git (fetch)
origin	git@github.com:your-repo/auth-plugin.git (push)
➜ git push

Viola! published code to my own repo.

Awesome Terminal Setup for OSX

Having a really efficient CMD line is awesome. It can save you a lot of time. It’s good to take the time to set up a terminal that is intuitive, customized to you and your workflow.

With the right software, you can do things like autocomplete your GIT and Docker commands and branches/images/containers. This alone is worth it. But also, you get DARK MODE!

My Favorite Setup

  1. iTerm2 – check out all the FEATURES. Replace your default Terminal with this NOW.
  2. Oh My Zsh – Steroids for your terminal. This gives us all the cool shit we need, like Autocomplete features, custom themes, and WAY MORE.

Go and install these two.

Docker/Git Auto complete

With iTerm2 and Oh My Zsh downloaded and installed, let’s add some plugins. Open your zsh profile, located in ~./.zshrc

edit the plugins section:

plugins=(
 git
 osx
 docker
 docker-compose
)

Now we get sweet autofill features. Here’s a list of hundreds more:

https://github.com/robbyrussell/oh-my-zsh/tree/master/plugins

Quick jump around CMD.

You can setup iTerm2 to let you jump around your current line, and way way more. Here’s your basics, jump around line.

https://stackoverflow.com/a/22312856/11406190

Follow that link to set it up!

Props to Rob Davis who shared these tips with me.

How to send an attachment through SOAP using MTOM (Message Transmission Optimization Mechanism) In Java

MTOM or the Message Transmission Optimization Mechanism is a low overhead way of sending attachments in a SOAP message. There are only two things that you have to do in addition to normal SOAP messages in Java, yet it’s a pain in the ass because it’s not properly documented anywhere.

I’ve put together this guide in order to make it more clear.

Assumptions

  • You’re proficient in Java (8) / Spring
  • You can glue together the code snippets I’m listing for you here
  • We are sending a Multipart file to our Java Server which will accept it and transmit it over SOAP protocol in MTOM format.

Let’s Code

  1. Setup Our Boilerplate

Controller accepts the file attachment of type MultipartFile

    @RequestMapping(value = "/attachments/upload", method = RequestMethod.POST)
    @Consumes(MediaType.MULTIPART_FORM_DATA)
    public void uploadAttachmentMTOM(@RequestParam MultipartFile file) {        
        attachmentService.uploadAttachmentMTOM(new AttachmentDTO(            
            file.getOriginalFilename(), 
            file.getBytes())
        );
    }

Service converts the MultipartFile DTO into our XML-SOAP WSDL object and sends it into the WebService that activates MTOM

public void uploadAttachmentMTOM(AttachmentDTO attachmentDto) {        
        UploadWSDL uploadRequest = UploadWSDL.from(attachmentDto);
        myWebService.sendAndReceive(uploadRequest, "soapActionFromWSDL");
    }

2. Enabling MTOM

Enable MTOM in Our WebServiceTemplate extension. This will be passed into the “sendAndRecieve” method.

public class MtomClient extends WebServiceTemplate {
    private static Jaxb2Marshaller MARSHALLER   = buildMarshaller("my_context_path");

    private static Jaxb2Marshaller UNMARSHALLER = buildMarshaller("my_context_path_2");

    MtomClient(String contextPath) {
        super(MARSHALLER, UNMARSHALLER);
        // This is the 2nd important thing that allows you to send MTOM
        // Enabling MTOM 
        MARSHALLER.setMtomEnabled(true);
        UNMARSHALLER.setMtomEnabled(true);
    }

    private static Jaxb2Marshaller buildMarshaller(String contextPath) {
        Jaxb2Marshaller marshaller = new Jaxb2Marshaller();
        marshaller.setContextPath(contextPath);
        return marshaller;
    }

Set a “SoapAction”. God knows what the hell this does, but it is absolutely required or else the JVM will not treat this like an MTOM message and shit will NOT work.

public class MyWebService {    

    /**
    * @param payload WSDL object
    * @param soapAction soapAction taken from WSDL
    */
    public JAXBElement<Object> sendAndReceive(Object payload, String soapAction) throws SoapConnectionException {

        try {                        
            return (JAXBElement<Object>) new MtomClient().marshalSendAndReceive(payload, message -> {

                // important part
                // With MTOM, if Soap Action isn't explicitly defined,
                // You'll get a 404 error 
                try {

                    SoapMessage soapMessage = (SoapMessage) message;                    
                    soapMessage.setSoapAction(soapAction);                    
                } catch (Exception e) {
                    // handle
                    // log error and abort
                }
            });                    
        } catch (final SoapMessageCreationException e) {
            // handle
        } catch (final WebServiceClientException e) {
            // handle
        } catch (final XmlMappingException e) {
            // handle            
        }

    }

}

That’s it. You should now be sending SOAP messages in MTOM format. If you need front-end code examples to go along with the backend code, here’s a github repo of both front and backend code:

https://github.com/sedkis/java-spring-js-MTOM-download

Please leave your comments below! Thanks.

Docker Secrets in multiple environments using a single Dockerfile

Your team may keep sensitive data in version control. Don’t do that. Better practice suggests that we inject our secrets into the environment in runtime instead. This allows us to keep our sensitive data in a password store, accessing it only when we need to.

The problem when we’ve many environments (dev, uat, test, qa, prod) is managing all the different Dockerfiles and secrets for each environment. Add in microservices where we multiply the number of environments by the number of services, and we get overwhelmed very quickly.

Today, we’ll show you how to solve this problem for an Enterprise level microservice architecture for 2-n environments using Docker.

There’s little overhead required to set this up, and in addition to making your security team happier, will trivialize your CI/CD pipeline by reducing the number of moving parts.

Technologies:

  • Docker
  • Docker Compose
  • Docker Secrets
  • Java (can be swapped out for any language)

This tutorial assumes you have decent understanding of Docker.

Setup

We’re launching our services in Docker containers. So we’ll create a Dockerfile for each service, and inject our secrets using the generic secret name, and then we can map an environment specific secret to it in actual runtime in our Compose files.

With this approach, we only need a single Dockerfile for all our environments.

  1. Create Docker Secrets in Each environment

Let’s log onto each environment and create the secret using Docker from cmd. Let’s pretend we have a single secret, single service, and two environments, dev and prod.

Dev

➜  echo "devpwd" | docker secret create service1-secret-DEV -
kgilm...

Prod

➜  echo "prdpwd" | docker secret create service1-secret-PRD -
w8fbl...

2. Create our Dockerfile for the microservice

Dockerfile

FROM openjdk:8-jdk

RUN mkdir -p /usr/app
WORKDIR /usr/app

COPY ./target/my-jar.jar .

EXPOSE 8181

CMD /usr/bin/java -jar \
  -Dweb.security.api.password="$(cat /run/secrets/service1-secret)" \
  ./my-jar.jar

We inject our secret using this line:

-Dweb.security.api.password=”$(cat /run/secrets/service1-secret)”

We tell Docker to inject the container with an environment variable called “web.security.api.password”. It will load it with the value of “$(cat /run/secrets/service1-secret)”.

When we add a Docker Secret to our container, it is automatically created as a file in the container under /run/secrets. The name of the file, “service1-secret” is the name of the secret.

3. Create Our Docker Compose files

Dev

version: '3.7'

services:
  my-java-service:
    image: 'my-java-service:latest'
    secrets:
      - source: service1-secret-dev
        target: service1-secret
      
secrets:
  service1-secret-dev:
    external: true

Prod

version: '3.7'

services:
  my-java-service:
    image: 'my-java-service:latest'
    secrets:
      - source: service1-secret-prd
        target: service1-secret
      
secrets:
  service1-secret-prd:
    external: true

We map the secret we created in the environment to the generic secret name being used by the Dockerfile.

That’s all! Just like that, we only need a single Dockerfile.

Was this helpful? Was anything missing? Please let me know by leaving a comment below. Thanks!

Hello world!

I wouldn’t be worth my salt as a developer if my first anything wasn’t some form of Hello World.

Some blog posts coming:

  • OMAD diet (One Meal A Day) and why I think you should try it
  • Remote Work and why I think you should try it

Yes I’m opinionated, but with good intentions!