Guests Archives | Clever Cloud From Code to Product Mon, 20 Nov 2023 16:26:08 +0000 en-GB hourly 1 https://staging-cc-assetsv6.cellar-c2.services.clever-cloud.com/uploads/2023/03/cropped-cropped-favicon-32x32.png Guests Archives | Clever Cloud 32 32 Reviewing BotPress on Clever Cloud https://stagingv6.cleverapps.io/blog/guests/2017/06/12/botpress-for-breizhcamp/ Mon, 12 Jun 2017 14:04:00 +0000 https://www2.cleverapps.io/wp/blog/technology/2017/06/12/botpress-for-breizhcamp/

This week, Benjamin Plouzennec & Antoine Cailly, Devs @ Zenika tell us about the chatbot they made for the BreizhCamp 2017, which is hosted on Clever Cloud. Can you introduce your bot? Breizhbot is a chatbot that quickly delivers information about the next talks during the event. We don't always plan in advance which talks we'll attend to so we often have to make a quick choice before the next round of talks. What's great about chatbots is that they are efficient! Very simple interaction and very optimized content delivery. Which framework did you use? We had the choice! Many big companies launched their framework and many more startups and open source projects appeared last year. But we wanted two things: easily connecting to several platforms and customizing the bot. For the first, we used Microsoft Bot Framework API to connect to Facebook Messenger, Skype, Slack and to publish a web UI. For the second we prefered using an open source framework called botpress that offers an evolutive architecture and has a nice community :-) As a proof of that, the connector between botpress and Microsoft Bot Framework didn't exist so we did it and published it. How did you discover Clever Cloud? We discovered it with Quentin Adam, a regular speaker in events we're attending to, and Benjamin already had a project hosted on Clever Cloud, My Virtual Story Book. What do you like most on Clever Cloud? Easy, the simplicity! As for our bot, the workflow is very efficient. We just linked our github repository, quickly tweaked the scalability params, added some environment vars and that was it: we had a chatbot up and running! What features are you expecting the most? For the moment the platform perfectly fits our needs. How would you describe Clever Cloud to someone who doesn't use it yet? Nice service, nice doc, nice people.]]>

This week, Benjamin Plouzennec & Antoine Cailly, Devs @ Zenika tell us about the chatbot they made for the BreizhCamp 2017, which is hosted on Clever Cloud. Can you introduce your bot? Breizhbot is a chatbot that quickly delivers information about the next talks during the event. We don't always plan in advance which talks we'll attend to so we often have to make a quick choice before the next round of talks. What's great about chatbots is that they are efficient! Very simple interaction and very optimized content delivery. Which framework did you use? We had the choice! Many big companies launched their framework and many more startups and open source projects appeared last year. But we wanted two things: easily connecting to several platforms and customizing the bot. For the first, we used Microsoft Bot Framework API to connect to Facebook Messenger, Skype, Slack and to publish a web UI. For the second we prefered using an open source framework called botpress that offers an evolutive architecture and has a nice community :-) As a proof of that, the connector between botpress and Microsoft Bot Framework didn't exist so we did it and published it. How did you discover Clever Cloud? We discovered it with Quentin Adam, a regular speaker in events we're attending to, and Benjamin already had a project hosted on Clever Cloud, My Virtual Story Book. What do you like most on Clever Cloud? Easy, the simplicity! As for our bot, the workflow is very efficient. We just linked our github repository, quickly tweaked the scalability params, added some environment vars and that was it: we had a chatbot up and running! What features are you expecting the most? For the moment the platform perfectly fits our needs. How would you describe Clever Cloud to someone who doesn't use it yet? Nice service, nice doc, nice people.]]> The End of the Fortress Metaphor https://stagingv6.cleverapps.io/blog/guests/2015/06/16/the-end-of-the-fortress-metaphor/ https://stagingv6.cleverapps.io/blog/guests/2015/06/16/the-end-of-the-fortress-metaphor/#comments Tue, 16 Jun 2015 14:04:00 +0000 https://www2.cleverapps.io/wp/blog/technology/2015/06/16/the-end-of-the-fortress-metaphor/

Geoffroy Couprie is a consultant in software security and an independent developer. He teaches development teams how to write safe software. This is the most seducing approach in IT security. This is also the worst. For more than 20 years now, people have believed that their network was a fortress, protected from the outside world by firewalls, NAT and DMZ. This idea is obsolete, we must change now. 20 years ago, it was still possible to see internal networks totally open, with every machine directly addressable from Internet. There were enough IPv4 addresses for everybody, the networks were small, life was good. But the security was atrocious: TCP stacks were remotely exploitable, worms were reproducing on corporate networks, internal file servers were publicly available, so people found the easiest way to secure everything on the cheap: isolate the network from the outside world. There's nothing wrong with that approach: it made sense at the time. As usual when someone finds a small, temporary hack instead of fixing everything, people kept improving it, approaching the local optimum. This led to firewalls on every machine, every network. People discovered that NAT could hide IP addresses, instead of simply allowing IP reuse, and thought it was a security feature. All of the nonsense about DMZ and airgapped networks appeared. Companies were actually selling hardware which would get packets from one network, disconnect (physically) from it, connect to another network, then send the packets. Airgap, yup. It worked for a time, since a lot of exploits in the 90s focused on remote exploits in operating systems and servers. If you cannot exploit the public face of the network, everything is alright.
The attacker is only one wrong click on a lovingly crafted PDF file away from your network.
Sysadmin taunting hackers
Unfortunately, we cannot think that way anymore. Web applications give too much entry points to your servers. Pivoting from a DMZ server to the internal network is easy, since internal users will also access those web applications. The attacker is only one wrong click on a lovingly crafted PDF file away from your network. Why would you concentrate on firewall rules when phishing is so effective? Once the attacker is in your network, it is over. Listen to traffic, elevate your privilege, pivot to another machine, impersonate users, traverse the whole network...
Traditional IT infrastructure
The fortress metaphor, where everything behind your firewall is safe and trusted, is dead. Your walls are useful, but not that much when the attacker can get insiders to help him, willingly or unknowingly. The goal is not to keep the attacker out of your system. It is to detect the threat, isolate it, find the attacker's path and heal the system. The attacker may have been in your network for months. How would you be sure he is not there anymore? There is a much better metaphor than the fortress, now. Think of your system as a city. The city can have walls, but to function properly, it should let people enter and get out. You cannot know precisely if everything in your city is legit. Chances are, someone uses his personal USB key. Someone else connected a WiFi router in his office. People are talking on Facebook, watching porn, using forbidden applications, like modern browsers. You will not be able to catch them, unless repression is your main tool, and this will not help them work. You want to reduce criminality in your city, but you will not eradicate it. You cannot prevent fires, but you can prevent them from spreading too far and too fast. If you imagine the attacker as already present on your network, you go from plugging holes in one wall, to verifying dependencies and access control between systems. The trusted network approach is flawed, you have to think in terms of authorization from one user/app/machine to the other. The attacker will explore your network from one node to the next connected one, from one access level to the upper one, and try to combine them. Defenders think in lists, attackers think in graphs. You must assume that the internal network is as dangerous as the Internet.
Assuming that servers will be safer if they are on your own network leads to a false sense of security.
This is also why the nonsense around private cloud has to die. Assuming that servers will be safer on your own network leads to a false sense of security. A system built from scratch to handle the worst of internet has a better chance to survive. What matters is access control granularity around data, users and applications. The network is not a security boundary anymore. ]]>

Geoffroy Couprie is a consultant in software security and an independent developer. He teaches development teams how to write safe software. This is the most seducing approach in IT security. This is also the worst. For more than 20 years now, people have believed that their network was a fortress, protected from the outside world by firewalls, NAT and DMZ. This idea is obsolete, we must change now. 20 years ago, it was still possible to see internal networks totally open, with every machine directly addressable from Internet. There were enough IPv4 addresses for everybody, the networks were small, life was good. But the security was atrocious: TCP stacks were remotely exploitable, worms were reproducing on corporate networks, internal file servers were publicly available, so people found the easiest way to secure everything on the cheap: isolate the network from the outside world. There's nothing wrong with that approach: it made sense at the time. As usual when someone finds a small, temporary hack instead of fixing everything, people kept improving it, approaching the local optimum. This led to firewalls on every machine, every network. People discovered that NAT could hide IP addresses, instead of simply allowing IP reuse, and thought it was a security feature. All of the nonsense about DMZ and airgapped networks appeared. Companies were actually selling hardware which would get packets from one network, disconnect (physically) from it, connect to another network, then send the packets. Airgap, yup. It worked for a time, since a lot of exploits in the 90s focused on remote exploits in operating systems and servers. If you cannot exploit the public face of the network, everything is alright.
The attacker is only one wrong click on a lovingly crafted PDF file away from your network.
Sysadmin taunting hackers
Unfortunately, we cannot think that way anymore. Web applications give too much entry points to your servers. Pivoting from a DMZ server to the internal network is easy, since internal users will also access those web applications. The attacker is only one wrong click on a lovingly crafted PDF file away from your network. Why would you concentrate on firewall rules when phishing is so effective? Once the attacker is in your network, it is over. Listen to traffic, elevate your privilege, pivot to another machine, impersonate users, traverse the whole network...
Traditional IT infrastructure
The fortress metaphor, where everything behind your firewall is safe and trusted, is dead. Your walls are useful, but not that much when the attacker can get insiders to help him, willingly or unknowingly. The goal is not to keep the attacker out of your system. It is to detect the threat, isolate it, find the attacker's path and heal the system. The attacker may have been in your network for months. How would you be sure he is not there anymore? There is a much better metaphor than the fortress, now. Think of your system as a city. The city can have walls, but to function properly, it should let people enter and get out. You cannot know precisely if everything in your city is legit. Chances are, someone uses his personal USB key. Someone else connected a WiFi router in his office. People are talking on Facebook, watching porn, using forbidden applications, like modern browsers. You will not be able to catch them, unless repression is your main tool, and this will not help them work. You want to reduce criminality in your city, but you will not eradicate it. You cannot prevent fires, but you can prevent them from spreading too far and too fast. If you imagine the attacker as already present on your network, you go from plugging holes in one wall, to verifying dependencies and access control between systems. The trusted network approach is flawed, you have to think in terms of authorization from one user/app/machine to the other. The attacker will explore your network from one node to the next connected one, from one access level to the upper one, and try to combine them. Defenders think in lists, attackers think in graphs. You must assume that the internal network is as dangerous as the Internet.
Assuming that servers will be safer if they are on your own network leads to a false sense of security.
This is also why the nonsense around private cloud has to die. Assuming that servers will be safer on your own network leads to a false sense of security. A system built from scratch to handle the worst of internet has a better chance to survive. What matters is access control granularity around data, users and applications. The network is not a security boundary anymore. ]]> https://stagingv6.cleverapps.io/blog/guests/2015/06/16/the-end-of-the-fortress-metaphor/feed/ 1 Smalltalk in The Cloud https://stagingv6.cleverapps.io/blog/guests/2015/01/05/smalltalk-in-the-cloud/ Mon, 05 Jan 2015 14:04:00 +0000 https://www2.cleverapps.io/wp/blog/technology/2015/01/05/smalltalk-in-the-cloud/

Geoffroy Couprie is a consultant in software security and a independant developer. After testing Clever Cloud for a while, he challenged himself trying to run Smalltalk on our PaaS. Here's the recap of his findings.

The Smalltalk world offers a radically different way to create and run software, and I have always loved to tinker with it. Thanks to the recent work around Docker at Clever Cloud, it is now possible to run Pharo Smalltalk apps, even Seaside ones, on this PaaS.

Thinking in Smalltalk

One of the most interesting features of Smalltalk is the image, which is a file containing a list of serialized objects. When you start your virtual machine, you load the image. When you stop, you serialise everything: classes, methods, instances of classes, windows, even running web servers. And when you start, you get back your environment in the same state. Even writing code is different: you are not editing a file, you are editing the implementation of a method, serialised like everything else in the image. That way, you can modify code while it is running easily.

The traditional method for deploying a web server consists in preparing the image with the code, and uploading the whole image on the server. This is at odds with deployment process at Clever Cloud, based on a simple Git push. So it requires a few steps.

Docker

Thanks to the recent developments around Docker support, it is now possible to run any language or platform on these servers. So I prepared two images, one to install Pharo Smalltalk on an archlinux Docker container, and the other, based on the first, to install the Seaside web framework.

There is nothing tricky in the first image, except needing to install lib32-zlib, lib32-ncurses and lib32-bzip2 to run the 32 bits VM on a 64 bits CPU.

The second image runs a .st file to download Seaside, remove default Seaside apps and deactivate the debug bar:

Gofer new
url:'http://www.smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main';
package: 'ConfigurationOfSeaside3';
load.
((Smalltalk at: #ConfigurationOfSeaside3) project version: #stable) load.

WAAdmin applicationDefaults removeParent: WADevelopmentConfiguration instance.
WADispatcher default handlers keys do:[:name | WAAdmin unregister:name].
Smalltalk snapshot: true andQuit: true.

Now, we have an image ready for deployment, and usable for all the future Seaside projects.

Preparing the code for deployment

We could save the image in a git repository, and push the whole file to Clever Cloud, but that would be too easy. What if we could send just the required code through git? Here comes FileTree, a library pre-installed in Pharo, that you can use to export code from the image and add it to a Git repository.

First, let's get some code to deploy. I will spare you the details, just get the WebCounter example from the Seaside book, it is doable under 10 minutes.

Done? Alright. Choose a folder that will contain the code you will push to the server, and git init in that folder. Now open the Monticello browser, add a new repository, select "filetree://" then choose your git folder.

Now select your WebCounter package in the Monticello browser, and save the code.

It should now appear in file form in the git folder:

$ tree .
.
└── WebCounter.package
    ├── WebCounter.class
    │   ├── README.md
    │   ├── instance
    │   │   ├── decrease.st
    │   │   ├── increase.st
    │   │   ├── initialize.st
    │   │   └── renderContentOn..st
    │   ├── methodProperties.json
    │   └── properties.json
    ├── monticello.meta
    │   ├── categories.st
    │   ├── initializers.st
    │   ├── package
    │   └── version
    └── properties.json

Loading the code

Now that we have an export of the Seaside component, we will create a Docker image to load the code. First, we need a small script to give the virtual machine at startup, to load the code and run it:

"this uses FileTree to load back the code from the /home/deploy folder"
(MCFileTreeRepository new directory: '/home/deploy' asFileReference) packageDescriptionsFromReadableFileNames  do:
  [:name || version |
  version := (MCFileTreeRepository new directory: '/home/deploy' asFileReference) versionFromFileNamed: name first, '.package'.
  [version load ]
        on: MCMergeOrLoadWarning
        do: [ :ex | [ ex load  ] on: MCNoChangesException do: [] ] ].

FileStream stdout nextPutAll: 'WebCounter installed'; lf.

"the Clever Cloud platform expects the app to listen on the 8080 port"
ZnZincServerAdaptor startOn: 8080.

"Register the code we just loaded on the /webcounter address"
WAAdmin register: WebCounter asApplicationAt: 'webcounter'.

Save that code as seaside.st, then we will create the Dockerfile to make it work on the server:

# -*- sh -*-
FROM geal/archlinux-seaside
MAINTAINER Geoffroy Couprie, contact@geoffroycouprie.com

ADD . /home/deploy

EXPOSE 8080

CMD ./pharo Pharo.image ./deploy/seaside.st

It reuses the archlinux-seaside image I prepared previously, copies the code from the repository in /home/deploy, then starts the image with the code loading script.

With this, you can build and run the image to test it:

$ docker build -t "geal/seaside-example" .
$ docker run -t -i -p 8080:8080 geal/seaside-example /bin/bash
[root@8e726df1bf4e home]# ./pharo Pharo.image ./deploy/seaside.st

UndefinedObject>>DoIt (WebCounter is Undeclared)
WebCounter installed

If you are on Linux, the website will be available on http://localhost:8080/webcounter. If you use OS X, run boot2docker ip, then access the server at http://<virtual machine IP>:8080/webcounter.

Creating the app on Clever Cloud and deploying

Go to https://console.clever-cloud.com, create a new application of type Docker, then get the git URL for your app, and do in your repository:

$ git remote add clever git+ssh://git@push.par.clever-cloud.com/<your app id>.git
$ git push clever master

And that's it! You can now access the Seaside component at http://<your_app_id>.cleverapps.io/webcounter.

At each new version of the code, export it to Git then push again, and the platform will redeploy everything automatically, rebuilding the Docker containers and the Pharo images. Now, you just need to add a few components to store state, like a database or S3 component, and you are good to go!

All the code is available on Github if you need to play with it:

]]>

Geoffroy Couprie is a consultant in software security and a independant developer. After testing Clever Cloud for a while, he challenged himself trying to run Smalltalk on our PaaS. Here's the recap of his findings.

The Smalltalk world offers a radically different way to create and run software, and I have always loved to tinker with it. Thanks to the recent work around Docker at Clever Cloud, it is now possible to run Pharo Smalltalk apps, even Seaside ones, on this PaaS.

Thinking in Smalltalk

One of the most interesting features of Smalltalk is the image, which is a file containing a list of serialized objects. When you start your virtual machine, you load the image. When you stop, you serialise everything: classes, methods, instances of classes, windows, even running web servers. And when you start, you get back your environment in the same state. Even writing code is different: you are not editing a file, you are editing the implementation of a method, serialised like everything else in the image. That way, you can modify code while it is running easily.

The traditional method for deploying a web server consists in preparing the image with the code, and uploading the whole image on the server. This is at odds with deployment process at Clever Cloud, based on a simple Git push. So it requires a few steps.

Docker

Thanks to the recent developments around Docker support, it is now possible to run any language or platform on these servers. So I prepared two images, one to install Pharo Smalltalk on an archlinux Docker container, and the other, based on the first, to install the Seaside web framework.

There is nothing tricky in the first image, except needing to install lib32-zlib, lib32-ncurses and lib32-bzip2 to run the 32 bits VM on a 64 bits CPU.

The second image runs a .st file to download Seaside, remove default Seaside apps and deactivate the debug bar:

Gofer new
url:'http://www.smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main';
package: 'ConfigurationOfSeaside3';
load.
((Smalltalk at: #ConfigurationOfSeaside3) project version: #stable) load.

WAAdmin applicationDefaults removeParent: WADevelopmentConfiguration instance.
WADispatcher default handlers keys do:[:name | WAAdmin unregister:name].
Smalltalk snapshot: true andQuit: true.

Now, we have an image ready for deployment, and usable for all the future Seaside projects.

Preparing the code for deployment

We could save the image in a git repository, and push the whole file to Clever Cloud, but that would be too easy. What if we could send just the required code through git? Here comes FileTree, a library pre-installed in Pharo, that you can use to export code from the image and add it to a Git repository.

First, let's get some code to deploy. I will spare you the details, just get the WebCounter example from the Seaside book, it is doable under 10 minutes.

Done? Alright. Choose a folder that will contain the code you will push to the server, and git init in that folder. Now open the Monticello browser, add a new repository, select "filetree://" then choose your git folder.

Now select your WebCounter package in the Monticello browser, and save the code.

It should now appear in file form in the git folder:

$ tree .
.
└── WebCounter.package
    ├── WebCounter.class
    │   ├── README.md
    │   ├── instance
    │   │   ├── decrease.st
    │   │   ├── increase.st
    │   │   ├── initialize.st
    │   │   └── renderContentOn..st
    │   ├── methodProperties.json
    │   └── properties.json
    ├── monticello.meta
    │   ├── categories.st
    │   ├── initializers.st
    │   ├── package
    │   └── version
    └── properties.json

Loading the code

Now that we have an export of the Seaside component, we will create a Docker image to load the code. First, we need a small script to give the virtual machine at startup, to load the code and run it:

"this uses FileTree to load back the code from the /home/deploy folder"
(MCFileTreeRepository new directory: '/home/deploy' asFileReference) packageDescriptionsFromReadableFileNames  do:
  [:name || version |
  version := (MCFileTreeRepository new directory: '/home/deploy' asFileReference) versionFromFileNamed: name first, '.package'.
  [version load ]
        on: MCMergeOrLoadWarning
        do: [ :ex | [ ex load  ] on: MCNoChangesException do: [] ] ].

FileStream stdout nextPutAll: 'WebCounter installed'; lf.

"the Clever Cloud platform expects the app to listen on the 8080 port"
ZnZincServerAdaptor startOn: 8080.

"Register the code we just loaded on the /webcounter address"
WAAdmin register: WebCounter asApplicationAt: 'webcounter'.

Save that code as seaside.st, then we will create the Dockerfile to make it work on the server:

# -*- sh -*-
FROM geal/archlinux-seaside
MAINTAINER Geoffroy Couprie, contact@geoffroycouprie.com

ADD . /home/deploy

EXPOSE 8080

CMD ./pharo Pharo.image ./deploy/seaside.st

It reuses the archlinux-seaside image I prepared previously, copies the code from the repository in /home/deploy, then starts the image with the code loading script.

With this, you can build and run the image to test it:

$ docker build -t "geal/seaside-example" .
$ docker run -t -i -p 8080:8080 geal/seaside-example /bin/bash
[root@8e726df1bf4e home]# ./pharo Pharo.image ./deploy/seaside.st

UndefinedObject>>DoIt (WebCounter is Undeclared)
WebCounter installed

If you are on Linux, the website will be available on http://localhost:8080/webcounter. If you use OS X, run boot2docker ip, then access the server at http://<virtual machine IP>:8080/webcounter.

Creating the app on Clever Cloud and deploying

Go to https://console.clever-cloud.com, create a new application of type Docker, then get the git URL for your app, and do in your repository:

$ git remote add clever git+ssh://git@push.par.clever-cloud.com/<your app id>.git
$ git push clever master

And that's it! You can now access the Seaside component at http://<your_app_id>.cleverapps.io/webcounter.

At each new version of the code, export it to Git then push again, and the platform will redeploy everything automatically, rebuilding the Docker containers and the Pharo images. Now, you just need to add a few components to store state, like a database or S3 component, and you are good to go!

All the code is available on Github if you need to play with it:

]]> Webelis agency tested Clever Cloud https://stagingv6.cleverapps.io/blog/guests/2012/11/27/webelis-tested-clever-cloud-with-joomla/ Tue, 27 Nov 2012 00:00:00 +0000 https://www2.cleverapps.io/wp/blog/technology/2012/11/27/webelis-tested-clever-cloud-with-joomla/ Webelis logo

Webelis is a web agency company mainly focused on Open Source CMS, with strong Joomla! expertise. Founded in 2009, the company has realised 100+ customers Joomla based websites. As a Joomla expert, Philippe decided to test the very latest Joomla 3.0 beta on the Clever Cloud Platform, in order to benchmark its overall performance.

“The fact is, I have been positively surprised in two ways:

  1. The Clever-Cloud setup/account creation process is very straight forward, without any hassle. I’ve been able to setup a full ready-to-go environment in less than 5 minutes. Deploying Joomla CMS is like a breeze, the FTP access and the database setup (pretty basic though) are standard compared to usual hosting providers (ftp/phpmyadmin), which is a good point.
  2. It’s all about performance. Wow. The Joomla instance is fast as hell. The site runs smoothly and page loading is near instantly. Believe it or not, the hosted site is much faster than my own local install using EasyPhp (running on a 2,53 Ghz core 2 duo / 4GB).

This first “hello cloud” test seems more than promising. Next step consists in deploying an existing Joomla-based website of mine, running on a popular hosting provider, in order to compare performance. I’m very curious and excited to see how the platform reacts under a heavy load.

About prices

Webelis logo

So far, though testing is completely free for the first steps, I intend to test the service in a deeper manner to see how much an average site can cost a month. This is where you may want to stay on a mutulalized hosting for small projects, and keep the Clever-Cloud high-end platform for projects that really need heavy load capabilities.”

Philippe Destré, CEO @Webelis

Thanks to Phillipe, we’ve noted the importance of giving a clear view on our pricing. That’s why we’ve published this week the Clever Cloud Pricing Sheet. Tell us what you think 😉

Oh! You should also note that Ouest Numérique‘s website is also a Joomla! site running on Clever Cloud!

]]>