Unlock Linux automation with 21.8 Robot!

Unlock Linux automation with 21.8 Robot!

We are proud to announce that with this community public preview release you can now run our UiPath Robot on Linux. Using Robots in Linux environments allows you to run unattended automations in Docker containers and provides a faster experience and an easier way of scaling up your deployment.

:warning: When Linux environments are used, robots can only run processes developed as cross-platform in Studio and do not require UI Interaction. For now, there is a limited number of activities that you can use for this process type, but we are actively working on adding new capabilities.

What do I need to try it out?

How can I use it?

There are 3 simple steps to run our Linux Robot on a machine that checks✔ all the prerequisites.

  1. Get the machine key and the Orchestrator URL for your robot.

  2. docker pull registry.uipath.com/robot/runtime

  3. docker run -e LICENSE_AGREEMENT=accept -e MACHINE_KEY="{machine_key}" -e ORCHESTRATOR_URL="{orchestrator url}" -ti -d registry.uipath.com/robot/runtime

Now, your Orchestrator should show the Robot as up and Connected.

For an extended how-to on installing the robot on a client machine and configuring it to connect to the orchestrator please find the documentation here

How to run my process?

The procedure for running an unattended job on Linux robots is identical to the one for Windows. You can find below the logs of MyFirstLinuxProcess

As the processes that can run on the container does not need a username or password, the Robot can be configured as credentials-less. For that, deselect Robot Credential from the Robot Setup for your user.

When to use cross-platform processes?

If your process requires to move data across multiple APIs you have an use case for this type of project. Take for example the following use cases:

  1. Import people profiles from Azure Active Directory to Slack
  2. Import people profiles from Azure Active Directory to Workday
  3. License management for Zoom
  4. .
    .
    .
  1. Auto-scale VMs on API based Hypervisor

Let us know what you think, how you would improve it and if you found any other issues. Thanks a lot!

29 Likes

Hi @erghe ,

This is fantastic news and I clearly see Automation Suite and Linux automation can improve allocation / scheduling of robots. Robot allocation and deallocation works like a charm on a machine template.

144 mb container size :+1:

I got this to work as you described here and the docs you linked. I am curious about the output from this command. Docker returns a GUID

What is the guid returned? Should I save that for the next time or will it be discarded and I run the command anew? (docker start {containerID})

Persisting logs is definitely a great feature. For example, we can run the robot in one container and have splunk / elastic search still have access to files on a network drive via another container.

As you correctly pointed out the use case is definitely in thousands.
The ease of running this makes me really excited. So essentially we can run this even on a RaspberryPi Zero.

Kudos again to the team.

3 Likes

Hi @jeevith,

I’m glad that you tested our Robot container. You can save that id for later (you are correct about it being the containerID), but you don’t need to. A simple docker ps -a will give you in the first column the containerID for the Robot, which are the first 12 characters from the ID returned by the docker run command.

Another mention that I want to add is that, right now, the docker image supports only the amd64 architecture (so no RPi Zero yet), but we are working to make images for other architectures as well.

Best regards,
Andrei

2 Likes

Thanks for the clarification.
So just docker start and docker stop commands are more than enough and the GUID is just a response.

Will be exciting to try this on arm.

Hi @jeevith,

Just to clarify this, as you can see in the image below, you need to specify which container to stop or start using the Container ID taken from the docker ps -a command. The ID you get is a response from the docker engine in order to confirm that the previous command was executed correctly.

You can check the docker documentation at docker start | Docker Documentation

Andrei

1 Like

Hi @erghe,

I got what you said with respect to the containerID which is 12 char string. The GUID I was pointing to earlier was


But as you said this is just a response from docker and all one needs to ensure is find the containerID of the UiPath Image (registry.uipath.com/robot/runtime) and use the start and stop commands in Docker as shown in the documentation

Just for fun, I have some ideas to integrate Linux Automation with Webtop by modifying the Docker Compose file. Docker running Linux on webbrowser running Docker running the UiPath robot. Close to inception!

Will share my findings if I manage to get it to work :slight_smile:

2 Likes

Very cool news! Looking forward to hearing more about Linux + UiPath working together!

1 Like

Awesome news - Can’t wait to try this out. Great work to all teams involved in delivering Linux Automation and Automation Suite. Thanks

2 Likes

This is super awesome!!! Will surely try this out to see the new experience :slight_smile:

2 Likes

Finally the team will be excited since we have some use cases with Linux. We will review and see if we can start something to review the usage on Linux.

wow. this will big impact for the cost.

Andrei,
It’s great news that Uipath support container platform. Kudos to the team.
Few questions:

  1. Which container tech Uipath support (Openshift, EKS, etc)
  2. When we create docker image, does it support any linux flavor base OS image (redhat or ubantu, etc)?
    Thanks.
    -vb
1 Like

Hi @Vinod_Bhatt,

Right now we support only Docker containers. The base image we are using is an Alpine Linux 3.13 with dotnet runtime installed.

If you are planning to make your own docker images, if you install the dotnet runtime, it should support any flavor base OS image.

Bes regards,
Andrei

1 Like

Hi @erghe, I tried that but I was unable to connect to the orchestrator. I’m using a self-signed certificate for the orchestrator. How do I make it trust the certificate?

Hi @rizistt,

This is not UiPath Robot specific, but Linux specific. If you have the rootCA.crt file you can use the following dockerfile to create a docker of your own that includes the self-signed certificate.

FROM registry.uipath.com/robot/runtime
ADD rootCA.crt /usr/local/share/ca-certificates/uipath.crt
RUN chmod 644 /usr/local/share/ca-certificates/uipath.crt && /usr/sbin/update-ca-certificates
ENTRYPOINT ["/root/application/startup.sh"]

The rootCA.crt certificate should be in the same folder as the Dockerfile and you should run the build command docker build -t myrobot-self-signed-cert . then run the new docker image that you have build using: docker run -e LICENSE_AGREEMENT=accept -e ORCHESTRATOR_URL="https://cloud.uipath.com/organization/tentant/orchestrator_" -e MACHINE_KEY="$KEY" -tid myrobot-self-signed-cert

Best regards,
Andrei

Thanks @erghe,

I did what you mentioned. Unfortunately, I was unable to get it up and running. I have attached the container logs for your kind information.

Any help would be appreciated.

Great…

Hi @erghe,

Re-installation of Docker Desktop did the trick. To be on the safe side, I updated the self-signed certificate and created a new image (as you mentioned above), and it worked.

I’m sure Linux + RPA will open so many new doors. Excited!!

Thank you!

3 Likes

We are proud to announce that the following UiPath IT Automation activity packages are now available for the Robot on Linux:

  • Amazon Web Services (AWS)
  • AWS Workspaces
  • Azure
  • Azure Virtual Desktop
  • Azure Active Directory
  • Google Cloud (GCP)
  • Citrix Hypervisor

The cross-platform UiPath IT Automation activities enable you to build automations for Cloud resources provisioning and management, ITSM and User Management, Desktop and App Virtualization, Server Virtualization.
Stay tuned for updated examples on github and on UiPath Marketplace.

6 Likes